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Foreward 

This  report  presents  a bottom  up  view  of  the  requirements,  industry  practices,  and  research 
questions  which  should  drive  new  methods  and  computer  tools  for  process  modeling  of  product 
realization.  It  does  not  prescribe,  or  even  discuss  in  detail,  formal  language  specifications  for  mod- 
eling product  realization  processes.  Comprehensive,  enterprise-level  models  of  the  diverse  human 
and  machine  task  interactions  necessary  to  build  an  electro-mechanical  product  are  still  premature. 
Instead,  we  have  tried  to  address  a wide  range  of  industry-relevant  modeling  issues  to  help  focus 
discussion  on  future  research  directions. 

Among  those  we  wish  to  thank  for  their  consultation  in  this  study  are  Daniel  Mark  and 
Drew  Jones  at  the  NASA  Goddard  Space  Flight  Center;  Korhan  Sevenler  and  Bud  Krayer  at  the 
Xerox  Corporation;  and  Amos  Freedy  and  Azad  Madni  at  Perceptronics,  Inc. 
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1.  Introduction 

The  purpose  of  this  document  is  to  identify  and  document  key  requirements,  industry  prac- 
tices, and  research  questions  which  should  drive  new  methods  and  computer  tools  for  process  mod- 
eling of  product  realization.  It  addresses  a wide  range  of  industry-relevant  modeling  issues  to  help 
focus  discussion  on  future  research  directions  and  its  intended  audience  are  modeling  researchers 
and  practitioners  in  industry,  universities,  and  other  federal  agencies.  Although  process  modeling 
methods  have  been  applied  to  many  types  of  development  efforts  (e.g.,  software  engineering,  VL- 
SI), our  sole  focus  in  this  report  is  realization  of  discrete  electro-mechanical  products. 

Manufacturing  firms  in  the  U.S.  and  worldwide  use  various  types  of  process  models  to 
study  their  product  realization  processes.  These  models  help  document  their  understanding  of  cur- 
rent (“as  is”)  operations  and  explore  possible  (“to  be”)  process  changes.  Despite  the  fact  that  these 
models  are  relatively  high-level  and  organizational  in  scope,  they  are  attracting  interest  among  de- 
sign engineers  and  systems  engineers.  For  electro-mechanical  products,  the  complex  task  interac- 
tions that  cross  functional  groups  and  departments  profoundly  impact  cost,  quality,  reliability  and 
time-to-market.  However,  they  are  extremely  hard  to  visualize  at  early  design  stages.  This  report 
attempts  to  identify  future  research  directions  within  a bottom  up  context  of  industry  PRP  model- 
ing requirements. 

How  might  new  computer-based  tools  enhance  PRP  modeling?  For  many  industrial  firms, 
both  the  methodology  and  data  in  their  process  models  have  been  understandably  proprietary  be- 
cause of  their  competitive  significance.  Hence,  there  has  been  relatively  little  dissemination.  This 
report  presents  some  of  the  industry  requirements,  existing  methods,  and  research  issues  for  pro- 
cess modeling  in  design  and  manufacturing.  It  also  suggests  possible  opportunities  for  exploring 
and  testing  new  process  model  architectures.  Observations  include  the  following: 

• Emerging  PRP  modeling  tools  are  reasonably  useful  for  visualizing  process  flow  at  mul- 
tiple levels  of  abstraction.  But  beyond  simply  documenting  activity  precedence  in  an  acyclic  di- 
rected graph,  PRP  models  have  only  very  limited  capabilities  to  characterize  design  iteration,  sup- 
port simulation  for  schedule  and  cost,  and  represent  time-dependent  information  flow  in  the  enter- 
prise. 

• In  contrast  with  process  planning  paradigms  in  manufacturing,  the  accuracy  and  precision 
of  PRP  models  are  inherently  limited  by  subjective  descriptions  of  human  tasks  and  task  interac- 
tions. There  are  also  significant  trade-offs  between  clarity  of  the  model  (by  limiting  details  of  com- 
plex interactions)  and  the  increased  modeling  effort  required  for  precise  output  metrics. 

• Meaningful  research  toward  new  PRP  modeling  techniques  will  require  extensive  access 
to  real  world  business  and  technical  data  from  diverse  functional  groups  within  commercial  man- 
ufacturing organizations.  Also,  new  mechanisms  to  validate  research  model  concepts  are  required. 

• Process  models  for  electro-mechanical  systems  are  inherently  more  difficult  than  for 
VLSI  design,  and  probably  even  software  design.  Product  complexity  breeds  process  complexity, 
and  the  mechanical  component  interactions  of  geometry,  heat,  vibration,  diverse  fabrication  con- 
straints, etc.  can  make  it  difficult  to  predict  process  sequence  beforehand.  As  Whitney  has  dis- 
cussed [Whitney  94],  the  well-structured,  top-down  design  processes  used  for  VLSI  design  offer 
few  useful  process  analogies  for  electro-mechanical  assemblies.  For  the  latter,  many  failure  modes 
cannot  be  predicted  by  existing  computer  analysis  tools,  and  are  uncovered  only  during  build/test 
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cycles.  This  is  particularly  true  for  assemblies  that  involve  vibrating  elements,  compressed  gases, 
or  other  distributed  system  interactions. 

Despite  these  caveats,  research  efforts  in  new  PRP  models  should  be  encouraged  because 
of  their  potential  pay-off  for  many  different  applications:  documentation  of  existing  best  practices, 
identifying  bottlenecks  (e.g.,  resource  constraints)  and  task  redundancy;  “what  if’  analyses  of  de- 
sign alternatives;  risk  assessment  for  schedule  and  cost;  archiving  PRP  processes;  training;  and 
many  others.  This  report  attempts  to  identify  future  research  directions  within  a bottom  up  context 
of  industry  PRP  modeling  requirements. 

2.  Definition  of  a PRP  Model 

The  term  PRP  model  (Product  Realization  Process  model)  will  be  used  in  this  report  to  help 
reduce  the  ambiguity  of  the  more  generic  term  “process  model.”  Definitions  of  “process  model” 
which  are  at  least  partially  relevant  to  the  content  of  this  report  can  be  found  in  [Busby  93,  Duffey 
93,  Kusiak  94,  Malone  93].  For  purposes  of  discussion,  the  following  working  definition  is  pre- 
sented: 

A PRP  model  is  a computer- intejrpretahle  description  of  the  human  and 
machine  activities  and  their  interactions  required  to  realize  a 
mechanical  or  electro-mechanical  product . This  may  include  early  concept 
and  configuration  design  activities,  detailed  design,  prototyping,  testing, 
tooling,  fabrication,  assembly  and  the  many  other  activities  within  the 
scope  of  the  realization  process . 

A PRP  model  should  at  least  be  a procedural  model  which  documents  precedence  relation- 
ships between  activities  in  a directed  graph,  and  serves  as  a visual  aid.  A more  robust  PRP  model 
is  parametric,  and  its  activity  representations  contain  attribute/value  pairs  for  assigned  resources, 
duration  times,  cost  rates,  etc.  By  using  stochastic  values  in  a parametric  PRP  model,  simulation 
techniques  can  help  estimate  uncertainty  and  risk  for  total  completion  time,  total  cost,  resource  uti- 
lization, and  other  aggregate  metrics  for  the  entire  process.  However,  there  are  serious  obstacles  to 
valid  parametric  models  given  the  complexity  and  uncertainty  of  real-world  product  realization  ef- 
forts, which  are  discussed  later  in  this  report. 

Due  to  multiple  connotations  of  the  term  “process  model”  by  different  engineering  and 
computer  science  communities,  it  is  also  useful  to  explain  what  it  is  not: 

• It  is  not  an  organization  model.  A process  model’s  scope  typically  crosses  departmental 
boundaries  and  in  fact  may  point  to  mismatches  between  departmental  responsibility  and  task  re- 
quirements. 

• It  is  not  an  information  model.  The  capability  to  represent  temporal  information  such  as 
process  sequence  and  related  time-dependencies  distinguishes  a process  model  from  an  informa- 
tion model. 

• It  is  not  just  a.  flowchart  of  the  generic  sequence  of  design  reviews  and  go/no-go  decisions 
mandated  within  a particular  corporate  environment,  without  reference  to  a specific  design  and 
manufacturing  effort. 

• It  is  not  a discrete  event  simulator  for  machine-executable  production  processes. 
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3.  Overview  of  PRP  Methods  and  Modeling  Issues  in  Manufacturing  Indus- 
tries 


In  current  practice,  there  are  at  least  two  conceptually  distinct  methodologies  used  for  pro- 
cess modeling  in  industry  which  merit  brief  introductory  cormnents.  Readers  familiar  with  PERT 
and  IDEE  might  wish  to  skip  sections  3. 1 and  3.2. 

3.1  PERT-based  Models 

Process  modeling  tools  for  product  development  efforts  have  been  used  since  at  least  the 
late  1950’s,  when  PERT  (Program  Evaluation  and  Review  Technique)  was  developed  to  manage 
scheduling  for  the  Polaris  missile  project  [Malcolm  59].  As  evidenced  by  its  many  commercial 
software  implementations,  PERT  remains  in  wide  use  (details  of  PERT  modeling  techniques  are 
widely  available  in  the  literature  and  will  not  be  presented  here).  However,  there  are  questions 
about  the  validity  of  PERT  modeling  for  product  development.  Among  product  managers  there 
seems  to  be  a general  consensus  that  PERT-based  commercial  project  management  software  has 
only  a very  limited  applicability  for  new  product  development  efforts.  Often,  these  are  used  only 
at  the  project  outset  to  define  very  rough,  graphic  procedural  relationships  among  activities.  Pro- 
gram features  such  as  slack  time  evaluation  and  resource  allocation  in  PERT  software  are  generally 
ignored  by  product  development  managers.  Comments  by  [Smith  91],  a manager  with  product  de- 
velopment experience  in  electronics,  are  representative  of  design  manager  attitudes  toward  these 
programs: 

Many  computer  programs  for  project  management  are  available  to  help  with  the 
planning  effort.  Although  most  of  these  programs  are  powerful  and  loaded  with  fea- 
tures, they  have  only  one  that  is  of  much  value  for  fast  track  development  projects: 
being  able  to  create  a picture  of  the  schedule,  either  in  bar  graph  (Gantt  diagram)  or 
network  (PERT  or  CPM)  form.  The  best  way  to  use  these  programs  is  to  produce  a 
giant  project  schedule  chart  and  post  it  on  the  wall  of  the  team  area  for  all  to  see  (a 
CAD  system  may  be  better  than  project  management  software  for  making  these  gi- 
ant charts).  Once  the  schedule  goes  up  on  the  wall,  it  should  stay  there,  in  contrast 
with  conventional  uses  of  project  management  software.  Normally  the  latter  pro- 
vides many  kinds  of  reports  that  are  to  be  generated  on  a regular  basis  as  the  sched- 
ule is  updated.  These  kinds  of  reports  are  geared  mainly  to  meeting  government 
contract  reporting  requirements  for  ponderous  projects  and  are  thus  inappropriate 
for  fast  development  projects.  [Smith  91,  p.  314] 

De  Wit  and  Herroelen  [De  Wit  90]  have  documented  many  flaws  and  inconsistencies  in 
PC-based  project  management  packages,  from  erroneous  completion  time  calculations  to  mislead- 
ing resource  monitoring  and  analysis.  Several  basic  serious  theoretical  flaws  have  also  been  well 
documented,  such  as  the  PERT  assumption  that  the  total  project  time  is  approximately  normally 
distributed  [Elmaghraby  77].  Perhaps  the  most  crucial  limitation  is  that  while  PERT  allows  uncer- 
tainty in  the  duration  of  activities,  it  assumes  the  existence  of  all  activities  are  determinant  (e.g., 
milling  machine  setup  and  machining  steps).  Iteration  of  activities  and  the  presence  of  contingency 
activities,  which  are  in  practice  a great  source  of  time  and  cost  uncertainty,  are  neglected.  Also  un- 
realistic is  the  basic  assumption  of  statistical  independence  of  activities.  These  assumptions  can  be 
particularly  limiting  when  applied  to  concurrent  engineering  activities  such  as  design  and  tooling. 
For  example,  in  the  worst  (but  not  uncommon)  case  for  tooling  design  and  fabrication,  a late 


PRP  Modeling:  Page  9 


change  in  the  product  design  can  result  in  scrapping  tools  and  beginning  anew  the  tooling  activi- 
ties. 

PERT  models  also  have  implementation  difficulties  in  common  with  any  activity  network- 
based  models  of  the  product  development  process.  Among  these  are  i)  the  often  informal  and  non- 
uniform  determination  of  which  activities  to  represent  at  what  level  of  detail,  ii)  the  difficulty  of 
modifying  a network,  once  built,  for  different  product  or  resource  configurations,  iii)  the  selection 
of  a probability  distribution  type  for  each  activity  duration  time,  and  the  subjective  estimate  of  its 
parameters  (e.g.,  the  arbitrary  selection  of  a beta  distribution  and  best/nominal/worst  case  param- 
eters used  for  PERT  models),  and  iv)  cost  modeling  limitations  related  to  inconsistencies  between 
the  activity  model  and  corporate  financial  practices.  An  excellent  overview  of  the  state-of-the-art 
for  theory  and  practice  with  activity  network  models  is  found  in  [Elmaghraby  94]. 

3.2  IDEF-based  Models 

The  Integrated  Definition  Methodology,  commonly  known  as  IDEE,  is  an  extension  of  a 
representation  scheme  known  as  Functional  Decomposition  Diagramming  (FDD).  IDEE  tech- 
niques emerged  in  the  mid-1970’s  as  part  of  the  U.S.  Navy  ICAM  initiative  to  increase  manufac- 
turing productivity  [ICAM  8 1 , Wisnosky  90].  In  more  recent  times,  many  large  corporations  have 
come  to  develop  their  own  “home  grown”  process  representations  and  modeling  procedures  based 
on  the  IDEE  methodology.  Various  extensions  to  IDEE  tools  have  been  developed  for  document- 
ing corporate  manufacturing  processes  at  Hewlett-Packard  [Marran  89],  United  Technologies 
[Davison  93],  and  elsewhere.  IDEE  has  also  apparently  been  widely  used  in  Japan  since  at  least 
1977,  despite  early  export  restrictions  on  the  DoD-funded  documentation.  A 1989  report  from  the 
Society  of  Manufacturing  Engineers  following  a trip  to  Japan  stated  that  many  of  the  largest  Japa- 
nese companies  visited  used  IDEE  for  modeling  both  manufacturing  and  business  processes  [Wis- 
nosky 94]. 

The  original  set  of  IDEE  representation  schemes,  BDEEO,  IDEEl,  and  IDEE  2,  were  intend- 
ed as  three  distinct  but  complimentary  system  models  from  the  functional/organizational,  informa- 
tional, and  behavioral  perspectives,  respectively.  Today,  IDEEO  and  IDEEIX  have  been  formally 
standardized  [EIPS183,  EIPS184]  and  are  being  widely  used  in  both  the  public  and  private  sectors 
for  the  modeling  of  a range  of  enterprises  and  application  domains.  Common  to  all  these  IDEE 
types  is  the  principle  of  “successive  decomposition,”  where  a simplified  system  diagram  at  a high 
level  of  abstraction  points  to  and  supports  a hierarchy  of  increasingly  detailed  views  of  system 
components. 

An  IDEEO  model  [Haines  90,  Kusiak  94]  is  primarily  a hierarchical  collection  of  diagrams, 
cross-referenced  with  accompanying  text  and  a glossary.  The  primary  components  of  an  IDEEO 
model  are  functions  and  the  interfaces  between  them.  Eunctions  are  represented  graphically  as  box- 
es, while  the  interfaces  (transfers  of  either  objects  or  data  between  functions)  are  denoted  by  inter- 
connecting arrows.  Each  function  box  in  the  model  represents  a state  transition  from  an  input  state 
to  an  output  state,  and  is  connected  to  the  other  functions  of  the  system  in  specific  and  clearly  spec- 
ified ways,  depending  on  the  types  of  interfaces  that  exist.  Each  arrow  represents  a particular  ob- 
ject or  piece  of  information  which  either  controls,  performs,  or  is  transformed  by  a function,  as 
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shown  in  Figure  1 . 
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Figure  1:  IDEFO  Representation 

Input  arrows  represent  any  materials  or  information  that  a function  will  operate  upon  or 
transform  during  its  execution,  while  output  arrows  denote  the  products  (also  in  terms  of  material 
or  information)  that  result  from  the  function.  Control  arrows  depict  the  conditions  or  circumstances 
that  govern  or  restrict  a function,  while  mechanism  arrows  represent  the  resources  or  tools  (e.g., 
persons  or  machines)  that  are  needed  to  support  or  perform  the  function.  Together,  two  or  more 
function  boxes  that  are  inter-linked  by  arrows  constitute  a constraint  diagram.  Within  such  a struc- 
ture, a given  function  cannot  commence  unless  its  required  inputs  and/or  controls  and  mechanisms 
(as  determined  by  the  interface  arrows)  are  provided.  The  way  in  which  the  activity  operates  de- 
pends on  the  exact  content  of  the  information  or  objects  conveyed  by  those  arrows.  Thus,  IDEFO 
diagrams  represent  only  the  constraints  which  exist  for  functions,  and  how  they  depend  upon  the 
outputs  of  other  functions  in  a process. 

An  IDEFO  diagram  may  appear  to  imply  a precedence  structure  between  process  activities, 
but  there  is  no  explicit  representation  of  activity  duration  or  process  activity  flow  in  this  type  of 
model  - it  is  static.  IDEFO  models  do  not  convey  the  timing  or  the  exact  sequence  in  which  func- 
tions will  occur,  and  so  they  are  not  directly  suitable  for  time-based  evaluations  (e.g.,  cost,  time- 
to-market,  resource  leveling,  etc.).  Feedback  and  iteration  can  be  captured  in  an  IDEFO  model, 
but  only  in  terms  of  functional  constraints,  not  actual  activity  process  flow  - there  is  no  time  di- 
mension. 

IDEFl  [ICAM  81a]  was  developed  as  a methodology  for  producing  information  models 
that  depict  the  relational  structure  and  semantics  of  information  within  systems.  Like  IDEFO, 
IDEFl  is  a formally  structured  graphical  technique,  but  is  based  in  relational  data  theory  and  enti- 
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ty-relationship  modeling.  DDEFl  was  later  enhanced  to  produce  IDEFIX,  featuring  enhanced  ca- 
pabilities for  relational  data  modeling.  The  basic  constructs  in  an  IDEFl  model  are  entities,  at- 
tributes, and  relationships.  Entities,  those  people,  places,  ideas,  things,  etc.  about  which  data  are 
kept,  are  represented  in  an  IDEFl  diagram  as  boxes.  These  entities  generally  correspond  to  the  con- 
straint arrows  of  a given  system’s  IDEFO  model,  although  the  mapping  requires  a translation  of 
format  - there  is  no  direct,  natural  correspondence  between  constraints  and  attributes.  Consequent- 
ly, a set  of  linked  glossaries  is  required  to  couple  and  allow  translation  between  the  IDEFO  and 
IDEFl  representations  of  a system.  Attributes  in  an  IDEFIX  model  are  descriptive  characteristics 
belonging  to  entities,  and  each  entity  has  its  own  particular  set  of  attributes,  shown  as  text  located 
within  the  graphic  entity  boxes.  Associative  relationships  and  connectivities  between  the  informa- 
tional entities  are  represented  as  lines  that  inter-connect  the  boxes  in  the  diagram.  In  short,  the  in- 
formational IDEFl  representation  for  a system  shows  how  the  arrow  labels  (constraints)  in  the 
functional  IDEFO  representation  of  that  system  are  related. 

IDEF2  was  developed  as  a means  of  producing  “dynamic  models”  intended  to  represent  the 
time-varying  behavior  of  systems  in  terms  of  the  functional,  resource,  and  informational  charac- 
teristics depicted  by  IDEFO  and  IDEFl.  However,  IDEF2  is  not  in  wide  use  today,  and  has  largely 
been  superseded  by  commercial  approaches  [Wisnosky  94]. 

It  should  also  be  noted  that  these  IDEF  methodologies  were  initially  developed  to  model 
very  large  scale  design  and  production  for  aerospace  and  other  defense-related  systems.  Attempts 
to  use  IDEF  for  modeling  in  other  domains  such  as  small  batch,  flexible  manufacturing  systems 
(e.g.,  apparel  manufacturing)  have  revealed  some  limitations  [Malhotra  92]. 

3.3  Traditional  PRP  Modeling  Practices 

When  one  looks  beyond  the  “best  practices”  in  the  more  advanced  manufacturing  corpora- 
tions, documentation  on  most  PRP’s  is  created  with  little  standardized  format,  at  a very  crude  level 
of  detail  and  without  consistency  of  activity  definitions.  Consider  an  application  of  a Gantt  diagram 
from  one  500-person  “mature”  manufacturer  of  metal  assemblies  forced  to  redesign  its  products 
due  to  competitive  market  pressures.  The  Gantt  diagram  in  Figure  2 was  produced  by  the  product 
development  team  (proprietary  references  have  been  omitted).  Each  activity  imphcitly  refers  to  the 
entire  product  assembly,  and  the  resulting  high  level  of  abstraction  makes  this  a document  of  very 
limited  use.  “Activities”  here  include  milestones  in  the  project,  beginning  and  ending  of  major 
project  phases  (e.g.,  “preliminary  design”),  and  specific  tasks  performed  by  marketing,  manufac- 
turing engineering,  product  engineering,  and  tooling  engineering.  The  “duration  time”  arrow  indi- 
cators group  large  numbers  of  these  activities  together  in  the  same  time  period,  and  do  not  portray 
dependency  or  precedence  relationships  between  individual  activities.  In  this  instance,  these  Gantt 
diagrams  were  distributed  to  department  managers  at  project  inception,  and  then  more  or  less  ig- 
nored when  later  design  iterations,  change  in  management  priorities,  and  delays  in  production  ramp 
up  occurred. 
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ACTIVITY 

WHO 

STATUS 

JAN 

FEB 

MAR  APR 

1 . start  formulation 

MKT 

M 

2.  market  specification 

MKT 

-> 

3.  end  formulation 

4.  start  preliminary  design 

PE,ME,TE 

R 

M 

5.  CAD  input  (shaded  images) 

PE 

R 

— > 

6.  stereolithography 

PE 

R 

— > 

7.  design/function  spec  comp 

PE 

R 

- — > 

8.  issue  matl  specs 

PE 

R 

— > 

9.  initial  product  review 

PE 

R 

— > 

10.  prelim  cost  parts  & matl 

ME 

- — > 

1 1 . prelim  process  cost 

ME 

— > 

12.  prelim  eng  analysis  doc 

PE 

R 

— > 

1 3.  prelim  parts  list  doc 

PE 

R 

— > 

1 4.  prelim  drwgs/dims 

PE 

R 

— > 

15.  rough  design  documented 

PE 

R 

— > 

16.  gage/fixture/tool  concepts 

ME 

— > 

17.  issue  critical  tolerances 

TE 

— > 

18.  long  lead  items  complete 

ME 

— > 

19.  prelim  capacity  analysis 

ME 

— > 

20.  risk  mngt  plan  issued 

ME 

— > 

21.  standard  cost  issued 

ME 

— > 

22.  tol  stud  (mjr  comp)  signed 

TE 

— > 

23.  inspect  & test  proc  issued 

QA 

— > 

24.  engineering  product  review 

PE 

> 

25.  prelim  dwgs  -all  parts  issued 

PE 

> 

26.  final  parts  list  issued 

PE 

> 

27.  potential  prob  analysis/risk 

TE 

> 

28.  end  preliminary  design 


MAY 


M 


Abbreviations: 

MKT  = Marketing  Dept.,  PE  = Product  Engineering  Dept.,  TE  = Tooling  Engineering  Dept. 

R = resource  conflict,  M = milestone,  “ — >”  = activity  duration 

Figure  2:  Gantt  Diagram  application  at  a mid-sized,  “mature”  manufacturer 
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3.4  Emerging  PRP  Model  Applications  in  Industry 

Beyond  their  traditional  role  as  a high-level  “road  map”  for  project  management,  PRP  mod- 
els are  being  called  upon  for  a range  of  applications.  For  example,  many  companies  have  been 
strongly  motivated  to  significantly  refine  their  PRP  models  when  they  decide  to  initiate  a system- 
level  integration  of  CAD  software.  Obviously,  the  introduction  of  integrated  CAD  systems  can  al- 
ter existing  processes  and,  ideally,  eliminate  certain  tasks  such  as  physical  prototyping  for  evalu- 
ating assembly  fits.  Constructing  “as  is”  and  “to  be”  models  provides  a basis  for  justifying  organi- 
zational change.  A related  application  has  been  to  document  and  revise  the  engineering  change  or- 
der (ECO)  process.  Watts  [Watts  84]  describes  the  use  of  such  models  to  aid  process  decision- 
making and  deployment  resulting  in  ECO  lead  time  reduction.  Process  modeling  tools  are  also  be- 
ing called  on  to  examine  requirements  for  supplier  chain  information  flow  in  distributed  product 
development.  For  example,  PRP  models  are  being  used  as  part  of  a project  to  examine  integration 
requirements  for  supplier  chains  for  automotive  and  military  applications  [ITI 94].  Both  interorga- 
nizational  and  internal  information  flow  of  the  “as  is”  system  is  being  modeled  as  a precursor  to 
developing  common  semantics  for  the  entire  procurement  process.  Most  recently,  industry  use  of 
PRP  models  has  been  promoted  under  the  guise  of  “Business  Process  Re-engineering”  (BPR). 

3.5  Industry  Requirements  for  PRP  Models 

What  are  the  decision-making  needs  of  engineers  and  managers  which  should  drive  devel- 
opment of  advanced  PRP  modeling  tools?  These  tools  should  help  evaluate  the  downstream  impli- 
cations of  complex  design  process  interactions  that  span  traditional  engineering  departmental  re- 
sponsibilities. Some  possible  scenarios  for  which  advanced  PRP  tools  might  be  useful  include; 

Best  Practices:  For  most  industries  it  is  critical  to  understand  successful  business  practices 
to  provide  a guideline  for  future  projects  and  product  development  efforts.  Equally  as  important  is 
the  documentation  of  “lessons  learned’  to  prevent  problems  from  being  encountered  and  solved 
again  and  again.  Many  industries  develop  these  guidelines  for  different  processes,  yet  usually  this 
information  is  static  and  maintained  in  paper  form.  Updates  to  these  guidelines  are  rarely  timely 
and  maintenance  becomes  a significant  barrier  to  acceptance.  Development  of  electronic  models 
can  enable  more  timely  updates  and  version  control  by  spreading  the  maintenance  across  more 
people. 

Cost  Estimation:  For  large  complex  projects  it  is  very  difficult  for  contractors  to  predict 
the  effort  required  to  meet  the  projects  objectives.  It  is  also  difficult  for  the  project  sponsor  to  de- 
termine if  the  contractors’  proposed  expenses  are  reasonable  to  meet  the  defined  objectives.  The 
development  of  a general  format  PRP  model  template  which  could  be  tailored  could  increase  a 
company’s  confidence  in  cost  estimations.  In  addition,  the  PRP  model  will  assist  in  identifying  key 
cost  drivers  which  might  reduce  costs  further  by  early  discussions  with  the  sponsor  on  cost  reduc- 
tion. 

Insertion  of  rapid  prototypes:  With  the  evolution  of  rapid  prototyping  technologies,  prod- 
uct realization  cycles  can  be  shortened  with  the  inclusion  of  rapid  prototypes  in  the  PRP.  By  in- 
cluding new  prototyping  subprocesses  in  a “to  be”  PRP  model  one  can  better  predict  their  impact 
on  the  product  realization  cycle  and  from  this  a more  informed  decision  on  process  improvement 
can  be  made. 
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Selection  of  materials:  Specification  of  different  materials  for  product  components  can  re- 
sult in  significant  product  improvements  (i.e.,  cost  reductions,  increased  reliability)  yet  associated 
with  this  decision  are  downstream  uncertainty  for  fabrication,  on-site  and  field  testing.  Depending 
on  the  functionality  of  the  component,  the  material  selection  might  affect  several  organizations  and 
these  considerations  need  to  be  planned  for  and  addressed.  To  do  this  requires  one  to  understand 
all  the  dependencies  associated  with  the  material  selection.  Often,  the  material  property  informa- 
tion is  very  limited  which  increases  the  uncertainty  and  risk  of  a specific  material  (for  example, 
some  polycarbonates  only  have  strength  data  derived  from  simple  tensile  testing).  Increased  risk 
also  results  if  product  functionality  uses  the  material  in  a novel  way  (high  impact  stresses,  intensive 
thermal  cycling). 

Evaluating  new  manufacturing  processes:  Introduction  of  different  or  innovative  manufac- 
turing processes  (e.g.,  metal  injection  molding  for  previously  machined  parts,  stereo-lithography) 
can  be  a source  of  uncertainty  for  downstream  activities.  Designers  and  manufacturing  engineers 
may  be  unfamiliar  with  practical  process  limits  and  their  effect  on  part  conformance  to  tolerance 
requirements.  In  addition  it  is  often  difficult  for  manufacturing  engineers  to  define  new  ramp-up 
activities  and  estimate  activity  durations  for  implementing  new  processes.  Manufacturing  engi- 
neers may,  in  some  cases,  strongly  resist  process  innovation  and  provide  unrealistically  negative 
estimates  of  time  and  cost  impacts.  Conversely,  managers  and  product  engineers  may  push  for  the 
new  process  with  unrealistic  expectations.  Representation  of  these  uncertainties  in  PRP  models  can 
assist  in  making  engineering  decisions  regarding  the  benefits  of  the  new  process. 

Selecting  a fabrication  method  for  prototype  builds:  Complexities  arise  when  managers  ex- 
amine the  consequences  of  prototype  fabrication  decisions  for  later  downstream  activities.  Are  the 
prototypes  built  with  the  same  manufacturing  processes  as  will  be  used  in  production  (for  example, 
wire  EDM  of  prototype  parts  when  progressive  dies  are  to  be  used  in  production)?  If  a different 
process,  then  downstream  delays  may  occur  when  the  production  tooling  and  set-up  issues  are  ad- 
dressed. Also,  dimensional  and  structural  properties  of  prototype  components  may  differ  in  ways 
that  seem  insignificant  in  preliminary  testing,  but  later  become  problems  (e.g.,  stress  concentra- 
tions that  occur  in  forming  but  not  metal  cutting). 

Number  of  preproduction  units:  Even  when  the  same  manufacturing  process  is  used,  how 
many  production  prototype  models  should  be  built?  Prior  to  final  design  sign-off  and  production 
tooling,  manufacturing  engineers  prefer  longer  test  runs,  while  management  is  anxious  to  enforce 
“concurrency”  by  minimizing  the  time  required  for  this  stage  of  development.  If  only  5 or  10  parts 
are  made,  then  the  machinists  and  other  direct  labor  involved  in  their  fabrication  will  treat  these  as 
“specials,”  and  many  of  the  problems  that  occur  in  actual  line  production  may  not  surface.  (For 
series  of  machining  operations  on  parts,  a rule  of  thumb  at  one  company  is  that  about  100  parts  are 
needed  to  validate  producibility.) 

Traditional  2-D  vs.  3-D  parametric  modeling:  Design  engineers  and  computer-trained 
draftsman  increasingly  advocate  the  use  of  3-D,  parametric  CAD  systems.  However,  serious  down- 
stream delays  may  occur  when  3-D  modeling  is  introduced  in  companies  that  do  not  restructure 
their  downstream  activities  to  make  use  of  these  systems.  Many  machinists,  cost  estimators,  tool 
designers,  etc.  still  only  know  how  to  analyze  2-D  graphical  data.  If  2-D  drawings  have  to  be  gen- 
erated from  a solid  model  representation,  the  work  required  for  layout  drafting,  revisions,  fixture 
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design,  etc.  can  actually  increase.  (Interestingly,  one  of  the  most  important  features  in  parametric 
modeling  systems  — which  many  promise  but  cannot  fully  deliver  ~ is  easy  generation  of  tradition- 
al 2-D  drawings  from  3-D  data.)  With  PRP  models  managers  have  a method  to  consider  the  impact 
of  advanced  CAD  systems  which  can  expedite  early  design  and  analysis,  but  actually  impede 
downstream  activities  that  still  rely  on  traditional  blueprints. 

Project  prioritization:  In  many  companies,  a list  periodically  circulates  that  prioritizes  dif- 
ferent product  efforts.  For  many  of  the  Product  Engineering  support  operations  such  as  drafting  and 
engineering  change  requests,  new  product  projects  directly  “compete”  for  priority  with  on-going 
minor  product  variant  efforts.  This  priority  listing  may  change  weekly  in  response  to  management 
perception  of  delivery  commitments.  Managers  have  difficulty  viewing  the  long-term  effect  of  this 
prioritization  on  new  product  lead-time  and  overall  company  objectives. 

Alternate  subassembly  configurations'.  Two  alternate  subassemblies  may  both  meet  func- 
tional requirements  and  spatial  constraints,  but  differ  in  use  of  physical  principles  and/or  manufac- 
turing processes.  For  example,  a sheet  metal  retaining  clamp  in  a battery-operated  beard  trimmer 
has  an  alternative  double-coil  spring  which  serves  the  same  function.  If  the  spring  is  purchased  but 
the  clamp  is  tooled  and  fabricated  in-house,  some  aggregate  measure  of  their  alternate  effects  on 
downstream  prototype  assembly,  pilot  runs,  etc.  is  desired. 

Budget  requests:  Both  manufacturing  and  product  engineering  managers  are  under  pres- 
sure to  submit  low-cost  budget  requests  for  development  activities.  Because  they  are  necessarily 
“uncertain”  what  the  actual  downstream  expenses  will  be,  they  are  forced  to  choose  between  i)  pad- 
ding known  line  items  in  the  request  with  hope  that  this  surplus  will  cover  contingencies  and  pos- 
sible design  “iteration,”  or  ii)  submitting  a lower-cost  budget,  then  face  the  unattractive  conse- 
quence of  petitioning  for  more  money  under  the  perception  that  they  are  “over  budget.” 

Schedule  assignment:  Typically,  groups  in  manufacturing,  design,  etc.  submit  their  desired 
schedules  to  upper  management,  upper  management  then  compresses  the  requested  time  for  each 
activity,  and  distributes  a “master”  schedule  for  the  project.  For  managers,  there  is  no  way  to  ex- 
plicitly examine  the  trade-offs,  for  example  between  greater  time  allotted  for  preliminary  design 
(e.g.,  more  thorough  testing  of  early  models,  or  more  early  effort  on  manufacturing  tolerances),  and 
more  time  for  downstream  manufacturing  ramp  up. 

Capital  expense  for  design:  Capital  expense  for  new  equipment  in  a design  engineering 
group  is  often  difficult  to  justify  compared  with  manufacturing  capital  requests.  A new  CNC  ma- 
chine can  be  easily  justified  in  cost  savings  to  production,  but  paying  $250,000  for  a stereolithog- 
raphy system  has  potentially  greater,  though  much  less  certain,  payback.  Development  cost  “sav- 
ings” are  difficult  to  discern  since  accounting  is  primarily  focussed  on  unit  production  costs. 

Engineering  change  order  requests'.  Invariably,  requests  for  design  changes  after  the  de- 
sign is  supposedly  “fixed”  are  made  by  marketing,  product  engineering,  and  manufacturing. 
Weighing  the  potential  cost  and  lead  time  effect  of  each  change  can  be  difficult.  This  is  particularly 
true  since  each  department  typically  signs  off  on  the  proposed  change  “in  series:”  the  paperwork 
travels  from  one  desk  to  another,  often  with  considerable  delays  between  departments. 

4.  Modeling  Issues  for  Advanced  PRP  Computer  Tools 

We  begin  with  some  caveats  about  the  subjectivity  inherent  in  product  realization  processes 
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that  distinguishes  them  from  strictly  machine-executable  processes.  The  modeling  implications  of 
this  subjectivity  might  be  grouped  into  two  areas:  1)  the  structure  of  the  model  (e.g.,  defining  ac- 
tivities and  their  precedence  relationships  in  a directed  graph),  and  2)  the  content  of  the  model  (e.g., 
values  of  activity  attributes  which  allow  parametric  characterization  of  activity  duration,  branching 
probabilities,  and  quantitative  evaluation  of  time,  cost,  etc.).  Because  they  model  sequences  of  hu- 
man-executable as  well  as  machine  executable  activities,  the  structure  of  a PRP  model  is  inherently 
subjective  in  its  capture  of  information  flow.  It  would  be  a mistake  to  consider  any  such  activity 
representation  as  a formal  function  representation  which  has  repeatable,  one-to-one  or  many-to- 
one  relationships  between  inputs  and  outputs.  The  nature  of  organizational  behavior  makes  a rig- 
orous mathematical  definition  of  its  semantics  unlikely.  Unlike  the  clear  sequence  of  fabrication 
activities  in  physical  process  planning,  PRP  models  must  often  characterize  a very  ambiguous  in- 
formation flow.  The  natural  tendency  for  those  constructing  the  model  is  to  define  activities  in 
terms  of  tangible  inputs  and  outputs  such  as  written  specifications,  analysis  results,  and  material 
transformations.  However,  much  information  flow  in  a PRP  is  less  easily  specified,  such  as  the  in- 
formal communication  network  built  up  in  an  interdepartmental  concurrent  engineering  team. 
Documenting  these  transactions  is  somewhat  analogous  to  problems  with  the  “knowledge  acquisi- 
tion” process  acknowledged  for  expert  systems  development. 

Beyond  simply  documenting  activity  precedence,  how  effectively  can  PRP  models  provide 
aggregate,  quantitative  metrics  such  as  total  cost  and  project  completion  time?  This  raises  issues 
about  the  subjectivity  of  content  in  a process  model  such  as  estimation  of  activity  duration  time  and 
assignment  of  branching  probability  values  (for  example,  the  pitfalls  of  assuming  beta  distributions 
for  modeling  time  uncertainty  in  probabilistic  PERT  models). 

With  these  caveats  in  mind,  some  of  the  many  representation  issues  for  advanced  PRP  mod- 
eling will  be  discussed. 

4.1  Activity  Network  Representations 

There  is  an  extensive  literature  in  activity  network  representation  and  related  graph  theory, 
but  we  need  only  introduce  some  nomenclature  to  help  frame  the  discussion  that  follows.  Many 
parametric  process  representations  which  extend  the  standard  PERT  representation  (e.g.,  to  in- 
clude stochastic  branching)  have  been  developed  for  general  use  since  the  mid- 1 960’ s.  Most  ad- 
vanced network  models  are  built  upon  antecedents  such  as  Graphical  Evaluation  and  Review  Tech- 
nique (GERT)  [Pritsker  66].  Both  activity-on-node  and  activity-on-arc  representations  are  used  in 
network  modeling  practice.  Visually,  an  activity-on-arc  representation  might  have  some  advantage 
since  it  could  potentially  display  time  scales  in  terms  of  arc  length.  Consider,  for  example,  how  a 
Generalized  Activity  Network  (GAN)  representation  as  defined  by  [Elmaghraby  77]  might  be 
adapted  for  PRP  modeling.  For  the  primary  building  block  in  the  network,  an  activity  (see  Figure 
3)  is  represented  as  a transition  (arc  Aj)  between  initial  and  final  states  (nodes  a,  b): 

© ►© 

Ai  = (Pi,  ti,  Cl) 

Figure  3:  Generalized  Activity  Network  (GAN) 
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The  parameters  for  the  vector  Aj  are; 

Pi:  probability  that  the  activity  occurs  given  that  node  a is  realized 

ti,:  the  duration  of  the  activity  (a  random  variable) 

cp  the  cost  of  the  activity  (a  function  of  tj  and  other  resource  usage) 

In  the  standard  nomenclature  for  GANs,  an  activity  has  receiver  and  emitter  logical  condi- 
tions associated  with  its  initial  and  final  states  which  are  graphically  displayed  in  two  halves  of  the 
nodes  such  as  those  shown  in  the  Figure  4 below. 


0 


“and” 

“exclusive-or” 


[)  “must-follow” 
“may-follow” 


RECEIVERS 


EMITTERS 


Figure  4:  Node  conditions  for  a GAN 

A logical  “and”  receiver  initiates  the  immediate  follower  activities  when  all  immediate  pre- 
ceding activities  have  been  completed.  A logical  “exclusive-or”  receiver  initiates  the  follower  ac- 
tivity when  one,  and  only  one,  preceding  activity  has  been  completed.  A “must-follow”  emitter  de- 
notes deterministic  realization  of  a follower  activity,  and  a “may-follow”  emitter  denotes  probabi- 
listic realization.  In  principal,  there  exists  an  analytic  approach  for  solving  a GAN  by  transforming 
the  network  to  one  which  contains  only  “exclusive-or”  emitters.  Under  the  assumptions  of  a semi- 
Markov  process,  this  network  then  will  have  an  analogous  representation  as  a signal  flow  graph, 
and  analytic  solution.  However,  an  analytic  evaluation  of  cost  and  time  distributions  for  activity 
networks  of  the  complexity  required  for  PRP  models  would  be  unwieldy;  either  some  PERT-type 
simplifying  assumptions  or  a simulation  approach  must  be  considered.  While  simulation  models 
have  been  used  extensively  and  successfully  for  modeling  manufacturing  processes  (e.g.,  queuing 
models  for  assembly  lines),  they  have  apparently  been  rarely  used  to  model  product  realization  pro- 
cesses. 

4.2  Representing  Design  Iteration  and  Activity  “Overlapping” 

There  are  certain  types  of  activity  iterations,  unique  to  discrete  product  realization,  which 
should  drive  advanced  PRP  modeling  efforts.  A much-cited  field  study  by  Clark  and  Fujimoto  pro- 
vides empirical  evidence  that  the  dependency  between  product  and  process  design  activities  is  an 
important  factor  for  determining  development  lead  time  [Clark  89].  In  a comparison  of  auto  body 
design  and  die  fabrication  activities  in  Japan  and  the  U.S.,  they  suggest  that  “overlapping”  of  these 
activities  can  shorten  development  time  if  information  processing  and  production  resources  are  ad- 
equate. Two  types  of  management  factors  are  identified  that  facilitate  effective  overlapping:  i)  the 
structuring  of  effective  communication  between  engineering  groups  to  allow  downstream  deci- 
sions based  on  incomplete  design  data,  and  ii)  choosing  the  earliest  time  to  commence  the  down- 
stream activity  (e.g.,  cutting  a contoured  die)  such  that  premature  commitments  are  minimized,  and 
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costly  iteration  of  die  design  and  fabrication  activities  is  avoided.  Ideally,  any  model  of  the  devel- 
opment process  to  aid  decision-making  should  represent  both  types  of  factors.  For  (i),  a model 
might  aid  decision-making  by  relating  uncertainty  in  product  information  to  uncertainty  in  total  de- 
velopment cost  and  time.  For  (ii),  a model  might  examine  alternative  times  for  commencing  “over- 
lapped” activities,  and  relate  each  to  total  cost  and  time. 

“Design  iteration”  is  a loosely  defined  term  which  describes  the  cycling  of  subgroups  of 
activities  typical  in  most  PRP  processes.  For  example,  one  particularly  costly  problem  with  design 
iteration  in  industry  is  design  and  tooling  activity  “iteration.”  There  are  many  anecdotal  examples 
of  this  conveyed  to  the  authors,  including:  i)  a “counter”  device  in  the  production  prototype  of  a 
high- volume  camera  which,  after  review  by  upper  management,  had  to  undergo  redesign  and  tool- 
ing rework;  ii)  a new  model  photocopier  in  pilot  production  which  was  discovered  by  marketing 
personnel  to  have  too  large  of  a “footprint”  for  its  intended  Japanese  market;  iii)  an  innovative 
small  firearm  already  in  pilot  production  which  required  considerable  redesign  and  retooling  due 
to  inadequate  specification  by  an  ammunition  supplier.  Another  example  of  “iteration”  in  the  de- 
sign cycle  for  downstream  tooling  activities  was  relayed  to  this  researcher  by  engineers  at  a large 
manufacturer  of  heat  pumps.  A product  line  consisted  of  a compressor,  heat  exchangers,  and  an 
accumulator  (i.e.,  thermal  capacitor)  placed  in  close  configuration  on  a base  plate  stamped  from 
cold  rolled  steel.  The  positions  for  these  heat  pump  subassemblies  determine  the  various  depres- 
sions and  punched  holes  in  the  base  plate  required  for  drainage,  from  which  a base  plate  design  is 
determined  and  sent  to  a progressive  die  vendor.  The  resulting  die  tooling  is  complex,  and  typically 
costs  $1/2  to  $3/4  million.  However,  after  the  base  plate  tooling  had  begun,  changes  to  the  “foot- 
print” of  the  compressor  and  other  subassemblies  would  occur  as  technical  advances  required  their 
redesign.  This  in  turn  required  that  the  entire  base  plate  tooling  be  scrapped  and  started  over  to  ac- 
commodate a new  configuration  of  the  subassemblies. 

Two  types  of  activity  interrelationships  that  defy  analytical  solution  for  the  resulting  net- 
work model  are:  i)  redesign  iteration  which  occurs  during  proof-of-concept,  production  prototyp- 
ing, and  other  phases  of  engineering  design,  and  ii)  changes  to  or  cancellation  of  manufacturing 
process  activities  concurrent  with  product  design  when  the  redesign  iteration  in  (i)  occurs.  For  the 
first  type,  design  is  often  informally  described  as  an  “iterative”  process,  and  in  fact  many  sequences 
of  activities  in  the  early  design  phases  are  repeated.  The  use  of  iterative  looping  in  an  activity  net- 
work is  an  imperfect  but  potentially  useful  representation  of  the  uncertainty  associated  with  activ- 
ity “overlapping”  as  described  by  [Clark  89]  and  identified  by  many  companies  as  “concurrent”  or 
“simultaneous”  engineering  of  product  and  process.  In  the  best  of  circumstances,  overlapping 
product  and  process  activities  can  significantly  shorten  development  cycles,  but  a high  level  of 
communication  is  required  between  design  and  manufacturing  engineers.  For  example,  a die  de- 
signer might  be  able  to  discuss  in-progress  styling  or  structural  features  proposed  by  a product  de- 
signer and  construct  a die  with  metal  unremoved  in  die  regions  where  he  anticipates  possible 
changes.  In  practice,  the  risk  in  this  approach  is  very  dependent  on  the  interpersonal  relationships 
among  engineering  group  members. 

In  terms  of  the  representational  requirements  for  concurrent  activity  interdependencies  de- 
scribed above,  it  is  instructive  to  examine  the  simplified  network  for  design  and  tooling  shown  be- 
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low  in  Figure  5. 


(Product  redesign  iteration) 


Figure  5:  Activity  interdependency  in  a GAN 

As  a way  to  simulate  the  concurrent  design  situation  described  above  using  this  model,  the 
production  tooling  activity/must  terminate  at  the  same  point  in  system  time  when  the  iteration  ac- 
tivity e is  realized  (i.e.,  the  duration  for/is  not  statistically  independent).  When  activities  h,  c and 
/then  occur  for  the  second  time,  the  parameters  for  the  distribution  functions  of  the  random  vari- 
ables and  tf,  have  changed.  Similarly,  the  branching  probability  Pg  should  also  change  after 
successive  redesign  loops. 

4.3  Uncertainty  Modeling  of  a PRP 

4.3.1  Some  Simulation  Considerations 

In  exploring  a simulation  approach,  it  should  first  be  noted  how  the  type  of  simulation  re- 
quired for  the  product  realization  process  differs  from  manufacturing  process  simulations.  Manu- 
facturing simulations  are  typically  based  on  queueing  models.  The  objective  is  typically  to  simu- 
late steady-state  workflow  conditions  in  a sequence  of  production  operations  where  successive 
units  come  “down  the  line.”  By  analyzing  the  simulation  results,  bottlenecks  in  processing,  buffer 
size  requirements,  capacity,  cycle  time,  and  other  parameters  can  be  identified  and  optimized  by 
changing  the  configuration  of  processing  tasks  and  resources  for  people,  equipment,  and  materials. 

By  contrast,  the  type  of  simulation  required  for  a product  realization  process  analyzes  a sin- 
gle “unit”  — the  design  itself  — as  it  increases  in  complexity  of  informational  and  physical  detail 
by  undergoing  tasks  within  the  various  company  departments.  In  the  nomenclature  of  simulation, 
a PRP  model  is  a “terminating  system.”  That  is,  there  is  a point  in  time  at  which  an  “epoch”  is  com- 
pleted and  all  discrete  events  cease.  This  is  in  contrast  to  a non-terminating  system,  for  which  dis- 
crete events  continue  indefinitely,  and  the  simulation  is  stopped  at  some  arbitrary  point  in  time.  Un- 
like in  a manufacturing  process,  the  description  of  the  “unit”  itself  is  not  predefined,  and  is  actually 
being  transformed  during  its  development.  Because  of  this,  there  is  uncertainty  inherent  in  task  du- 
ration and  iteration  that  is  not  present  in  a manufacturing  simulation.  Time  variability  in  manufac- 
turing simulations  is  typically  aggregated  from  delay  times  in  queues  and  by  machine  down-times 
on  a production  line  (that  is,  by  waiting  times  between  the  fixed  task  times  in  a production  se- 
quence). However,  in  a PRP  simulation,  virtually  all  task  times  must  have  variability  and  iterative 
loops  must  be  characterized.  Also,  due  to  the  abstract  nature  of  product  realization,  the  network 
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configuration  and  parameterization  of  activities  is  more  subjective;  any  output  from  a PRP  simu- 
lation is  subsequently  less  precise. 

4.3.2  Activity  Duration  Uncertainty 

Analysis  of  the  total  time  and  cost  uncertainty  for  a product  realization  process  is  dependent 
on  characterization  of  uncertainty  in  individual  activity  durations.  In  common  practice,  probability 
distributions  assigned  for  product  development  activities  are  often  quite  arbitrary  (e.g.,  the  beta 
distribution  assumption  in  the  commonly  accepted  PERT  network  model)  and  are  based  on  analo- 
gous activity  distributions  evidenced  in  physical  manufacturing  processes.  Activity  times  in  a PRP 
model  might  fall  into  two  general  classes:  lead  times  and  work  times.  Lead  times  (e.g.,  delay  times 
for  many  “over-the-wall”  hand-offs  of  design  information  within  an  organization)  might  be  repre- 
sented by  exponential  distributions.  Processes  modeled  by  the  exponential  distribution  include 
queues  (for  banks,  grocery  check  outs,  etc.),  time  between  failures  in  electronic  devices,  duration 
times  of  telephone  conversation,  and,  in  general,  many  processes  modelled  using  the  theory  of  con- 
gestion systems.  Work  time  distributions  (time  to  create  a detailed  design,  prototype,  etc.,  as  well 
as  order  time  for  purchased  components,  subassemblies,  or  materials)  are  perhaps  best  represented 
by  a two-tailed  distribution  skewed  to  the  right  which  might  be  modeled  by  beta  (used  in  PERT), 
gamma  or  other  distributions.  Many  studies  of  “work”  activities  have  shown  them  to  be  gamma 
distributed,  such  as  many  manual  tasks  in  assembly  operations  [Hoover  89].  One  convenient  prop- 
erty of  using  exponential  and  gamma  reference  distributions  is  the  ease  with  which  distribution  pa- 
rameters can  be  estimated  from  sample  means  and  standard  deviations.  (This  contrasts  with  param- 
eter estimation  for  the  beta  distribution,  for  which  multiple  parameter  values  are  possible  given  es- 
timates of  mean  and  variance,  and  which  leads  to  problems  under  the  simplifying  assumptions  of 
the  PERT  model.) 

Computational  costs  are  another  consideration.  For  a practical  PRP  model  with  upwards  of 
100  activities  and  using  Monte  Carlo  simulation,  random  variate  generation  will  contribute  consid- 
erably to  CPU  time.  Computation  is  relatively  simple  for  the  exponential  distribution,  and  a simple 
inversion  method  is  adequate  for  random  variate  generation.  However,  for  the  gamma  distribution, 
and  in  general  for  most  two-tailed  asymmetric  distributions,  random  variate  generation  is  some- 
what more  involved.  For  example,  random  variates  for  the  gamma  distribution 


/(a,  P) 


to.-\e  P 

P“r(a) 


[Eq.  1] 


are  most  simply  generated  for  the  case  of  P = 1 (the  standard  gamma  distribution).  Different 
algorithms  are  required  for  the  cases  of  a > 1 and  a < 1 (a  = 1 is  simply  the  exponential  distribu- 
tion). Of  the  possible  algorithms  described  by  [Dagpunar  88],  all  are  iterative  in  that  a rejection  test 
is  required  for  the  generator.  For  a > 1 an  approach  can  be  used  based  on  the  ratio  of  two  uniformly 
distributed  random  variables.  Intensive  simulation  of  large-scale  PRP  networks  with  hundreds  of 
activities  is  quite  computationally  expensive. 

Yet  another  duration  uncertainty  issue  is  the  changing  status  of  cost  and  time  estimates  as 
the  project  progresses.  A Bayesian  methodology  has  been  suggested  to  update  distributions  as  ac- 
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tual  cost/time  data  is  fed  back  into  the  system  during  project  execution  [Huseby  93]. 


4.3.3  Concurrent  Activities  and  Stochastic  Modeling 

As  discussed  regarding  the  limitations  of  PERT  models,  the  mean  and  variance  for  the  ag- 
gregate time  of  the  network  may  differ  substantially  from  the  sums  of  the  expectations  for  individ- 
ual activities  along  a deterministic  “critical  path.”  In  general,  the  greater  the  number  of  parallel  arcs 
in  the  network  the  greater  the  discrepancy  between  total  time  as  predicted  from  a PERT  model  and 
the  actual  expectation  of  the  network  time.  For  many  traditional  applications  of  a PERT  model,  in 
which  there  are  relatively  few  parallel  paths  and  a single,  dominant  “critical  path”  exists  (e.g.,  con- 
struction projects),  this  discrepancy  may  not  present  a problem.  For  product  realization  processes, 
however,  this  discrepancy  could  be  quite  large.  Consider  an  example  assuming  multiple  parallel 
paths  (Figure  6)  where  the  completion  time  of  each  is  an  identical  random  variable  T,  (analogous 
to  the  problem  in  reliability  theory  for  the  prediction  of  failure  rate  for  components  in  parallel.)  For 
simplicity,  assume  that  the  paths  are  identically  distributed  with  the  uniform  distribution  U(0,b). 


Figure  6:  Parallel  paths  (concurrent  activities)  in  activity  network 


The  total  completion  time  X = Max  (Tj,  T,...,  TJ,  and  for  the  cumulative  distribution  func- 
tion. 


F^{x)  = FjJ,x)  ■ FjJ,x)...  -Fjix) 


[Eq.  2] 


[Eq.  3] 


if  independence  for  the  uniformly  distributed  completion  time  of  each  path  is  assumed.  For 
the  p.d.f.. 


f(x)  = 


[Eq.  4] 


for  which  the  expectation  is 


PRP  Modeling;  Page  22 


b 


EX  = ^xf{x)dx 
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[Eq.  5] 
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and  the  variance  is 


VarX  = E{X^)-EX^ 


[Eq.  6] 


b 


+ 1 J (n  + 1 )^(n  + 2) 


nb  V _ nb^ 


[Eq.  7] 


0 


intuitively  expected,  the  mean  of  the  total  completion  time  will  always  be  larger  than  the  mean  time 
of  any  single  path. 

Estimating  total  completion  time  uncertainty  in  an  activity  network  is  also  related  to  the 
level  of  detail  of  the  activities  being  characterized.  The  time-to-completion  variance  of  a single, 
high-level  “activity”  will  be  greater  than  the  summed  variances  of  subdivided,  lower-level  activi- 
ties if  one  assumes  (as  is  done  for  PERT  models)  that  i)  the  total  expected  time  of  the  subdivided 
activities  at  the  lower  level  of  detail  is  equal  to  the  expected  time  of  the  single,  aggregate  activity, 
and  ii)  the  range  of  the  subdivided  activities  equals  the  range  of  the  aggregate  activity.  In  addition, 
analysis  of  time  and  cost  variability  for  complex  networks  is  complicated  by  subjective  estimates 
of  distribution  parameters: 

There  is  little  doubt  that  the  estimates  of  the  parameters  of  individual  activities  com- 
bine in  a complex  manner  to  yield  the  estimate  of  the  variance  of  the  project  dura- 
tion. Errors  in  such  parameters  introduce  errors  in  the  final  result,  whose  magnitude 
and  direction  remain,  to  date,  largely  undetermined.  [Elmaghraby  77,  p.  258] 

4.3.4  Alternative  Representations  of  Uncertainty 

Although  a probabilistic  concept  of  uncertainty  is  used  for  activity  duration  in  most  models, 
there  are  other  mathematical  tools  available  to  characterize  time  variables,  and  provide  for  binary 
operations  on  those  variables.  One  possible  method  might  be  a relatively  simple  application  of  Za- 
deh’s  extension  principle  for  fuzzy  numbers  [Wood  89].  As  an  example,  a variable  such  as  activity 
work  time  for  a particular  life-cycle  stage  would  be  denoted  not  by  a discrete  value  but  by  i)  an 
interval  of  confidence  [1,  u];  and  ii)  a membership  function  which  assigns  a membership  a G [0,1] 
to  define  the  level  of  confidence  for  values  within  the  interval  (0  is  least  confident  and  1 is  most 
confident).  For  example,  work  time  durations  for  prototyping  P and  testing  T might  be  denoted 


P = [p,  Pj.]  = [10,  20]  days  and  T = [tj,  t^]  = [15,  30]  days 
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with  corresponding  membership  functions  shown  in  Figure  7 below. 


P T 

Figure  7:  Examples  of  fuzzy  membership  functions 

The  completion  time  for  both  prototype  and  testing,  at  a given  level  of  confidence,  would 
be 

Ca  = Pa  ® Ta  = [P,“  ,C  > P'!- 

= [(2a  + 10)  + (5a  + 15),  (-8a  + 20)  + (-10a  + 30)]  [Eq.  9] 

where  © is  the  fuzzy  addition  operator.  For  confidence  intervals  for  at  alpha  levels  0, 
0.5,  and  1.0, 

Co  =[25,  50] 

Co5  = [28.5,41] 

Cj  = [32,  32] 

This  type  of  uncertainty  characterization  has  not  been  widely  used  for  activity  network 
modeling,  however,  and  network  analysis  difficulties  are  likely.  It  is  mentioned  here  only  as  a pos- 
sible alternative  to  the  probabilistic  characterization. 

4.4  Representing  Economic  Information 

Ideally,  a PRP  modeling  tool  would  help  evaluate  the  strategic  economic  impact  of  candi- 
date product  and  process  design  configurations.  Design  trade-offs  could  be  examined  for  their  im- 
pact on  both  costs  and  revenues,  and  related  uncertainty,  during  the  entire  product  life-cycle.  We 
will  first  discuss  some  cost  modeling  issues  and  then  examine  the  potential  for  more  “strategic” 
economic  analysis  within  a PRP  model. 

One  obvious  cost  analysis  problem  for  PRP  models  is  determining  the  differential  impact 
of  product  and  process  changes  using  data  tied  to  traditional  overhead  allocations  in  industry  ac- 
counting practices.  For  example,  for  many  traditional  manufacturers,  new  product  design  is  rela- 
tively infrequent,  and  competes  for  scarce  engineering  resources  with  on-going  manufacturing  and 
minor  design  variations  to  existing  product  lines.  Their  cost  accounting  practices  often  assign  over- 
head costs  for  their  product  development  efforts  using  an  accounting  “base”  formulated  for  on-go- 
ing production.  New  activity-based  costing  (ABC)  methods  seem  to  be  relevant,  and  have  begun 
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to  be  incorporated  in  commercial  EDEF-based  process  modeling  tools  for  “Business  Process  Re- 
engineering.” Other  relevant  work  on  activity-based  cost  modeling  includes  work  by  Bloch  [Bloch 
92]  and  Reimann  [Reimann  94]. 

Time-dependent  costs  are  another  issue.  One  approach  might  be  to  modify  traditional  cost 
models  to  enhance  PRP  model  sensitivity  to  the  time-to-market  implications  of  design  decisions. 
For  example,  Ulrich  [Ulrich  91]  suggested  the  following  cost  model  after  studying  Polaroid’s  prod- 
uct development  efforts: 


C = V(m  + l+p)-i-F  + S-i-D-i-T  [Eq.  10] 

C:  total  manufacturing  cost  of  the  product  over  its  lifetime 
V:  total  production  volume  over  the  product  lifetime 
m:  unit  material  cost 
/:  unit  direct  labor  cost 

p:  unit  production  resource  usage  cost  (e.g.,  machine  time  cost) 

F:  product  specific  capital  costs  (e.g.,  tooling,  jigs,  and  fixtures) 

S:  system  costs 
D:  development  costs 
T:  time  costs 

In  this  model,  the  terms  V and  F on  the  right  hand  side  contain  the  traditional  costing  terms 
described  previously.  M,  I,  and  p correspond  are  the  unit  material  and  variable  costs,  and  F corre- 
sponds to  the  fixed  costs.  The  terms  S,  D,  and  T are  traditionally  not  considered  in  product  cost 
evaluations.  S refers  to  those  institutional  system  costs  that  are  normally  aggregated  as  overhead 
costs  for  direct  production  cost  rates.  These  include  industrial  engineering,  plant  maintenance  op- 
erations, material  control,  purchasing,  and  other  functions.  D refers  to  development  costs:  direct 
labor  for  engineering  staffs  involved  in  product  and  process  design,  product  modeling  costs,  and 
other  non-recurring  expenses  prior  to  on-going  production.  T is  a cost  associated  with  the  total 
product  development  lead  time.  This  time-related  cost  is  generally  not  explicitly  considered  in  a 
financial  evaluation  of  the  product.  It  may  include  revenue  loss  due  to  late  market  entry,  a shift  in 
present  worth  or  internal  rate  of  return  (IRR)  for  capital  expenses,  or  an  opportunity  loss  cost  due 
to  delayed  technology  introduction  following  along  time-to-market. 

Ulrich  posits  that  for  certain  product  types  for  which  short  lead  time  is  critical  for  compet- 
itiveness, this  cost  T is  important  or  even  predominant,  and  new  product  cost  models  are  required 
to  evaluate  its  magnitude  and  dependency  on  changes  of  product  attributes.  This  time  criticality, 
he  states,  makes  some  of  the  established  design-for-manufacturing  heuristics  inadequate  for  these 
product  types.  In  a field  study,  his  research  group  examined  a late  production  model  of  a Polaroid 
camera  - a large  volume  consumer  product  for  which  short  lead  time  is  critical  to  sales  of  both  the 
camera  model  and  its  self-developing  film.  Engineering  designers  had  followed  an  accepted  DEM 
convention:  reduce  the  number  of  parts  to  simplify  assembly  operations,  even  when  the  resulting 
parts  require  increased  complexity  (e.g.,  replacement  of  screws  by  snap  fits).  As  a result,  one  single 
injection-molded  part  in  the  camera  frame  required  an  exceedingly  complex  design  to  accommo- 
date part  reduction,  ease  of  assembly,  and  multiple  functionality.  The  lead  time  for  its  injection 
mold  tooling  was  considerably  longer  than  any  other  part,  and  therefore  determined  the  critical  ac- 
tivity path  for  the  entire  camera  development  effort.  Development  costs  as  defined  by  this  model 
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are  considered  to  be  difficult  to  assess  because 

the  relationship  between  part  details  and  engineering  effort  is  considerably  more 

complex  than  the  other  relationships  we  have  modeled.  [Ulrich  91,  p.  13] 

Development  costs  were  assumed  to  be  “roughly  independent  of  the  design  details,”  and 
were  neglected  in  the  Ulrich  model.  However,  in  many  companies,  the  proportion  of  operating 
costs  related  to  engineering  development  of  new  products  is  growing  substantially,  but  the  cost 
measurements  of  these  development  activities  continue  to  be  tied  to  activities  within  the  same  de- 
partments and  work  units  that  support  on-going  manufacturing.  In  some  cases,  seemingly  routine 
design  detail  decisions,  particularly  those  which  have  some  element  of  risk  related  to  innovative 
product  function  or  manufacturing  process,  can  affect  development  costs  substantially. 

Many  multinational  manufacturing  firms  use  computerized  business  simulations  to  train 
executives  and  explore  alternate  scenarios  for  “strategic”  business  decisions  (for  example,  these 
have  a long  history  in  the  auto  industry  [Bonini  63]).  Their  economic  modeling  concepts  might 
have  application  for  PRP  modeling  tools.  However,  their  cost  modeling  methods  appear  to  still  be 
based  on  simple  variations  of  the  traditional  production  function  concept  in  economic  theory.  The 
standard  Cobb-Douglass  production  function,  for  example,  assumes  only  crudely  defined  inputs  of 
labor  and  materials.  Gold  [Gold  92]  and  others  are  experimenting  with  production  function  refine- 
ments for  manufacturing  business  simulations.  Son  [Son  92]  has  also  developed  a manufacturing 
cost  simulation  methodology  using  advanced  cost  accounting  principles. 

Modeling  the  downstream  revenue  impact  of  design  decisions  has  begun  to  attract  interest 
in  the  design  engineering  community.  Devor  and  Cook  [Cook  91],  both  prominent  mechanical  en- 
gineering academics,  have  attempted  to  frame  the  “demand  side”  of  design  evaluation  within  a 
larger  “strategic”  economic  model.  In  actual  practice,  though,  modeling  tools  that  incorporate  rev- 
enue are  limited  to  simple  spreadsheets.  [Smith  90]  has  described  this  traditional  cash  flow  ap- 
proach; for  a “baseline”  development  scenario,  annual  revenue  is  projected  during  market  life  from 
selling  price  and  expected  unit  sales,  and  development,  production,  marketing,  and  distribution 
costs  are  assigned.  Variations  to  this  baseline  scenario  can  then  be  examined,  such  as  delayed  time- 
to-market,  product  cost,  product  performance,  and  development  expense.  Smith  argues  that  since 
only  very  approximate  data  is  available  at  the  early  design  stage,  such  models  must  be  very  simple. 
For  example,  to  examine  trade-offs,  he  encourages  use  of  rough  rules-of  -thumb  such  as  “$100,000 
of  additional  development  expense  per  1%  increase  in  performance”  [Smith  90].  It  is  unclear  to 
what  extent  more  systematic,  detailed  methods  of  cost  and  revenue  estimation  might  improve  this 
type  of  cash  flow  approach  within  a computer-based  PRP  modeling  tool.  Fairly  accurate  estimation 
of  a revenue  curve  has  historically  been  possible  only  for  certain  product  types.  In  particular,  com- 
panies which  can  ehcit  marketing  feedback  from  well-organized  distribution  and  service  channels 
and  have  a fairly  stable  competitive  environment  (some  examples  are  air  conditioners  and  furnac- 
es) have  historically  made  fairly  accurate  predictions  in  the  five-year  range  for  unit  sales  of  new 
products.  In  general,  though,  and  particularly  in  a new  era  of  more  dynamic  international  markets, 
this  type  of  revenue  prediction  is  extremely  difficult.  However  revenue  flow  can  sometimes  at  least 
be  parameterized  using  a scheme  such  as  that  described  by  Haffner  [Haffner  88]. 
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4.5  Data  Collection  and  Validation  Issues  for  PRP  Models 

Obviously,  the  collection  of  valid  data  to  populate  a PRP  model  is  critical  [Busby  93].  For 
reasons  already  cited,  these  data  will  certainly  be  less  precise  than  for  a machine-executable  pro- 
duction process.  Defining  discrete  activities  - let  alone  iteration  loops  - is  sometimes  arbitrary.  For 
example,  tolerancing  on  part  drawings  may  be  done  partially  by  a design  engineer,  partly  by  a 
draftsperson,  and  partly  by  manufacturing  personnel  at  different  stages  prior  to  fabrication.  For  as- 
signing activity  durations,  there  are  a variety  of  established  techniques  for  subjective  estimation  of 
probability  distributions  in  network  models.  These  include  the  Normalized  Geometric  Vector 
method,  the  Modified  Churchman- Ackoff  Method,  and  the  Delphi  Technique  (an  overview  of  the 
use  of  these  and  other  methods  for  cost/time  data  uncertainty  can  be  found  in  work  by  Stewart 
[Stewart  87]).  For  less  formal  parameter  assignments  for  activity  times,  either  historical  data  from 
similar  projects  or  subjective  estimates  can  be  used  to  obtain  mean  and  standard  deviation  values. 
The  relationships  between  resource  allocations  and  activity  durations  is  also  problematic.  (In  fact, 
some  would  argue  that  an  inverse  relationship  exists  in  some  cases.  In  Japan,  which  has  the  shortest 
design  cycles  for  most  discrete  product  groups,  the  number  of  core  design  engineers  for  many  elec- 
tro-mechanical products  is  typically  less  than  30,  while  design  staffing  for  similar  products 
U.S.  may  be  in  the  hundreds.  [Whitney  90]). 

More  generally,  some  difficulties  for  parametric  PRP  modeling  should  be  made 
[Wall  91]  has  discussed  time  and  cost  estimation  for  a field  study  of  prototyping  activities 
Kodak  Apparatus  Division; 

A number  of  factors  make  estimating  processing  time  and  cost  difficult.  First,  the 
reliability  and  consistency  of  the  estimator  has  to  be  established.  In  many  organiza- 
tions estimating  is  still  more  art  than  science;  often  the  estimators  would  produce 
one  estimate  then  start  over  as  they  realized  a more  elegant  solution  to  the  fabrica- 
tion problem.  Second,  we  had  to  define  where  one  process  finished  and  another 
started,  and  we  had  to  define  the  “average”  target  level  of  performance  for  each  pro- 
cess. For  example,  a stereolithography  part  destined  for  the  paper  path  of  a copier 
required  more  hand  finishing  time  than  a similar  stereohthography  part  designed  to 
hold  rolls  of  film.  Third,  the  skill  levels  of  the  operators  were  also  an  issue.  Fourth, 
we  often  found  variations  within  a given  process;  a given  part  can  often  be  fabricat- 
ed by  a given  process  a number  of  different  ways.  Finally,  the  capacity  utilization 
level  of  the  process  determines  the  time  a part  will  spend  waiting  for  the  process. 

For  the  time  estimates,  we  assumed  that  capacity  utilization  was  low  enough  that 
the  queueing  effects  were  negligible.  This  will  only  be  true  in  organizations  that  al- 
locate enough  capacity  to  prototyping  that  jobs  move  through  the  shop  without  con- 
tending for  resources.  [Wall  91,  p.  153] 

This  last  assumption  by  Wall  (negligible  waiting  time  to  begin  an  activity)  was  quite  rea- 
sonable within  the  context  of  his  study,  but  is  probably  unrealistic  for  modeling  time-to-market  de- 
termination within  the  context  of  most  companies. 

There  are  considerable  difficulties  to  industry-relevant  validation  of  experimental  PRP 
models.  This  holds  for  their  process  visualization  capabilities  as  well  as  parametric  properties  for 
predicting  aggregate  cost  and  time  estimates,  etc.  Validating  an  aggregate  development  cost  and 
time  model  with  “real”  industry  cost  and  time  data  is  difficult  for  three  reasons:  i)  only  a subset  of 
design  and  manufacturing  activities  is  typically  modeled,  ii)  current  accounting  practices  at  most 


in  the 

clear, 
at  the 


PRP  Modeling:  Page  27 


companies  cannot  provide  meaningful  comparison  to  activity-based  costing,  iii)  “to  be”  models 
are  essentially  un-calibrated  in  terms  of  distribution  parameters  for  activity  durations,  branching 
probabilities,  and  conditions  for  dynamically  changing  state  variables  in  the  network.  Ulrich  [Ul- 
rich 9 1 ] has  discussed  similar  validation  problems  for  aggregate  development  time-dependent  cost 
models  in  the  course  of  field  research  at  Polaroid: 

Even  defining  accuracy  within  the  context  of  a cost  model  of  this  type  is  difficult. 

The  problem  is  that  actual  costs  are  incurred  at  a very  aggregated  level  over  some 
period  in  the  past  and  we  would  like  to  estimate  what  future  costs  will  be  under  a 
different  set  of  conditions.  The  manufacturing  system  is  much  too  large  and  expen- 
sive to  run  model  validation  experiments.  The  best  one  could  do  is  to  compare  pre- 
dictions with  outcome  for  the  one  particular  set  of  design  choices  that  happen  to 
emerge  in  the  next  product  cycle.  Instead,  we  carefully  examine  the  underlying  as- 
sumptions of  our  model  and  attempt  to  justify  each  of  its  constitutive  elements.  If 
we  believe  the  assumptions,  we  should  believe  the  implications  of  the  arithmetic 
linking  the  assumptions  to  cost.  The  power  of  models  like  these  is  that  they  facihtate 
exploratory  calculations.  Researchers  and  program  managers  can  test  the  impact  of 
different  detail  design  strategies  under  different  sets  of  assumptions  to  gain  insight 
into  how  detail  designs  impact  manufacturing  system  performance.  [Ulrich  9 1 , p.7] 

4.6  Knowledge-Based  Representations  in  PRP  Models 

Though  some  PRP  modeling  packages  have  claimed  to  be  “knowledge-based,”  their  use  of 
this  term  refers  mostly  to  generic  graphical  and  data-linking  enhancements.  We  have  discovered 
no  existing  models  which  can  embed  domain-relevant  “knowledge”  about  activities  and  their  in- 
teractions that  significantly  enhances  either  model  construction  or  analysis.  However,  there  are 
several  ways  that  one  might  envision  using  knowledge-based  design  paradigms  for  PRP  models. 
For  example,  automated  evaluation  of  tooling  or  assembly  complexity  (e.g.,  component  interac- 
tions, tolerancing)  might  be  used  to  assign  activity  duration  times  and/or  iterative  redesign  branch- 
ing probabilities  based  on  historical  corporate  process  data  for  similar  products  (as  an  example, 
Malhajan  [Mahajan  91]  has  automated  estimation  of  tooling  lead  times  for  progressive  dies  based 
on  feature-based  component  representations.  See  also  work  by  Hu  [Hu  94]).  Other  knowledge- 
based  methods  might  be  used  for  default  assignment  of  resources  (people,  machines)  to  activities, 
or  to  aid  analysis  of  process  bottlenecks.  A list  of  “performable  activities”  associated  with  each  re- 
source, which  contains  those  activity  classes  with  which  the  resource  can  be  automatically  matched 
(but  not  necessarily  selected)  might  also  included  in  a resource  representation.  Resource  represen- 
tations might  also  include  a measure  of  productivity  rate  for  each  associated  activity.  Obviously, 
the  usual  difficulties  with  knowledge-based  systems  - scale-up,  knowledge  acquisition  and  updat- 
ing, coding,  etc.  - would  require  a high  entry  cost  for  these  types  of  model  enhancements. 

There  may  be  a role  for  “critic  theory”  and  debiasing  methodologies  in  PRP  modeling  to 
help  participants  create  and  evaluate  a process  model  beyond  their  particular  technical  focus  area 
and  in  terms  of  strategic  organizational  objectives.  In  practice,  anecdotal  evidence  suggests  that 
a product  manager’s  decision-making  may  be  strongly  biased  by  his  or  her  particular  work  back- 
ground and  technical  expertise.  A manufacturing  manager,  for  example,  may  push  to  reduce  the 
test  phase  on  a proof-of-concept  model  without  fully  understanding  the  implications  of  functional 
problems  which  might  appear  later  on  in  pilot  production.  A design  engineer  may  assign  complex 
part  geometries  and  excessively  tight  tolerances,  but  have  little  knowledge  of  the  resulting  process 
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control  difficulties  and  long  tooling  lead  times.  A marketing  specialist  may  change  product  speci- 
fications with  inadequate  understanding  of  the  often  hundreds  of  costly  and  time-consuming  engi- 
neering changes  this  will  precipitate  for  product  and  process  redesign.  There  has  been  some  limited 
work  in  applying  critic  theory  to  design  which  may  merit  further  investigation  for  PRP  modeling. 

One  approach  to  knowledge-based  PRP  modeling  is  to  consider  a comprehensive  represen- 
tation of  a PRP  as  a triple  (P,  A,  R),  for  which  P = {p}  is  the  set  of  product  elements,  A = {a}  is  a 
set  of  activity  classes,  and  R = {r}  is  the  set  of  resources  available  for  realization.  Each  element  in 
each  set  has  in  turn  certain  properties  (e.g.,  p = {s}).  These  properties  denote  hierarchical  ordering 
within  each  set  (i.e.,  level  of  detail)  and  mapping  between  product-activity  sets  and  between  activ- 
ity-resource sets  (Figure  8),  as  well  as  other  information  required  for  cost,  time,  and  other  evalua- 
tions. (Variations  of  this  approach  have  been  presented  by  Cralley  [Cralley  89],  Duffey  [Duffey 
93]  and  others.) 


PAR 


Figure  8:  Product  Element,  Activity  Class,  and  Resource  data  sets 

By  convention,  classes  of  product  elements  P in  mechanical  assemblies  can  be  structured 
hierarchically  by  defining  each  element  as  a sub-assembly,  component,  or  feature  (e.g.,  a sub-com- 
ponent level  element  which  has  both  form  and  functional  or  manufacturing  intent).  Resource  class- 
es R can  also  be  hierarchically  ordered  similar  to  a company  organization  chart  for  departments  of 
product  and  manufacturing  engineering,  tooling,  marketing,  finance,  as  well  as  available  outside 
vendors,  prototyping  facilities,  etc.  “Leaves”  in  this  resource  tree  may  be  people  or  machines  or 
some  combination  of  the  two.  However,  a classification  scheme  for  realization  activity  classes  A 
is  more  problematic  than  for  product  elements  or  resources.  For  purposes  of  discussion,  a tentative 
hierarchy  of  design,  prototyping,  and  other  realization  activity  classes  is  shown  in  Figure  9.  Prod- 
uct realization  activities  concern  the  design,  building,  and  evaluation  of  physical  and  analytical 
models  prior  to  production  runs.  Production  realization  activities  concern  the  tooling  and  manu- 
facturing ramp-up  prior  to  on-going  production.  Much  activity  interdependence  occurs  between 
these  two  groups.  Decision  point  activities  are  the  periodic  management  evaluations  which  ap- 
prove and  allocate  money  for  successive  project  stages,  and  may  determine  reworking  of  in- 
progress product  or  process  designs.  The  “leaves”  of  this  activity  hierarchy  tree  (see  Figure  9)  are 
the  smallest  units  of  activities  meaningful  for  development  cost  and  time  estimation  purposes;  that 
is,  those  activities  for  which  explicit  numbers  of  machine  and  human  resources,  and  capital  expen- 
diture, can  be  identified.  A separate  but  interesting  discussion  of  activity  taxonomies  can  be  found 
in  work  by  Malone  [Malone  93]. 
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Figure  9:  Example  hierarchy  of  activity  classes 
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5.  New  Methodologies  and  Software  Implementations 

5.1  A Petri  Net-based  Model 

A Petri  Net-based,  object-oriented  process  modeling  software  package  has  been  used  by 
NIST  researchers  in  some  recent  industry  test-bed  PRP  modeling  experiments.  The  following  is  a 
discussion  of  the  modeling  methods  and  implementation  issues  realized  in  CACE/PM  (Computer 
Aided  Concurrent  Engineering/  Project  Management,  hereafter  referred  to  as  CACE)^  The  focus 
of  this  section  is  to  highlight  generic  modeling  issues  and  not  issues  relating  to  this  specific  mod- 
eling methodology. 

The  CACE  modeling  methodology  [Madni  93,  Madni  93a]  purports  to  capture,  visualize, 
simulate,  and  analyze  actual  or  planned  PRP’s.  The  representation  features  multiple  levels  of 
abstraction  (e.g.,  an  exposition  of  a hierarchy  of  tasks,  subtasks,  and  activities  within  a process), 
and  can  be  viewed  from  multiple  perspectives  (e.g.,  tasks  or  resources).  The  major  component  of 
a CACE  representation  is  the  process  flow  (aka  control  flow)  model,  which  makes  use  of  the  so- 
called  Modified  Petri  Net  (MPN)  methodology  and  notation  [Madni  88].  As  the  name  suggests, 
the  MPN  representational  scheme  is  an  adaptation  of  general  Petri  nets  [David  94,  Peterson  81, 
Reisig  92]  which  have  their  roots  in  the  original  work  of  C.A.  Petri  in  1962.  Like  a basic  Petri  net, 
the  MPN  is  a graphical  (but  also  highly  computer-implementable)  representation.  An  MPN  graph 
is  made  up  of  four  types  of  primitives:  circles,  boxes,  vertical  bars,  and  directed  arcs.  Circles  rep- 
resent human  or  machine-automated  processes,  tasks,  or  activities  which  occur  over  a period  of 
time,  while  boxes  represent  passive  “hold”  or  “wait”  states  through  which  process  flows  can  be 
suspended  or  synchronized.  Vertical  bars  denote  state  transitions  or  events  that  mark  the  termina- 
tion of  one  activity  or  hold  and  the  start  of  another  in  a flow.  Activities  or  holds  are  connected  to 
events  in  an  alternating  fashion  via  directed  arcs  to  establish  a process  control  flow  sequence,  as 
shown  in  Figure  10. 

MPN’s  appear  to  offer  a number  of  properties  desirable  for  PRP  modeling,  such  as  the  rep- 
resentation of  processes  with  cycles,  iterations  and  choices,  in  addition  to  shared  resources  and 
interdependencies  between  parallel  or  concurrent  activities.  An  MPN  graph  also  offers  a hierar- 
chical decomposition  similar  to  EDEF  representations  in  the  way  that  each  activity  circle  within  an 
MPN  can  be  made  a “parent  tasknet”  which  points  to  a “subnet”  of  sub-activities  at  a lower  level 
of  abstraction.  Associated  with  each  activity  circle,  hold  box,  and  event  bar  in  the  MPN  is  a 
“frame”  through  which  additional  process  information  can  be  included  about  such  things  as  activ- 
ity durations,  resource  requirements,  knowledge-based  rules,  and  conditional  or  probabilistic 
expressions  for  controlling  activity  parameters  or  process  flow  during  simulation.  The  resources 
that  will  be  utilized  by  activities  in  the  course  of  executing  a process  can  also  be  incorporated, 
modeled  in  a resource  hierarchy  which  exists  separately  from  the  MPN.  Various  resource  classes, 
such  as  People,  Machines,  and  Tools  can  be  defined,  along  with  multiple  subclasses  and,  ulti- 
mately, the  actual  resource  instances  that  perform  process  activities.  These  resource  instances  are 
allocated  to  the  activities  of  a CACE  process  model  by  linking  them  to  the  appropriate  frame(s)  in 
the  MPN. 


1 . Certain  commercial  applications,  equipment,  instruments,  or  materials  are  identified  in  this  paper. 
Such  identification  does  not  imply  recommendation  or  endorsement  by  the  National  Institute  of  Standards  and  Tech- 
nology, nor  does  it  imply  that  the  products  identified  are  necessarily  the  best  available  for  the  purpose. 
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Figure  10:  Example  of  a CAGE  Tasknet  (Process  Flow  Model) 

Once  an  “as-is”  CAGE  process  model  has  been  documented  and  constructed,  it  can  be 
executed  via  a built-in  discrete-event  simulation  routine  that  can  be  visualized  as  a process  flow 
animation.  MPN’s  execute  in  a fashion  similar  to  “regular”  Petri  nets  by  propagating  “tokens” 
(which  can  be  thought  of  as  status  markers)  through  the  chain  of  activities,  holds,  and  events,  in  a 
sequence  dictated  by  the  layout  of  the  directed  arcs,  defined  activity  durations,  and  any  imbedded 
conditional  statements  or  rules.  A token  propagates  from  an  input  (or  “upstream”)  activity  circle 
(or  hold  box)  to  its  subsequent  output  (“downstream”)  activity  if  the  conditions  associated  with 
the  event(s)  connecting  the  input  and  output  activities  occur,  thus  causing  the  transitional  event(s) 
to  “fire”  and  transfer  control  down  the  line.  Unlike  basic  Petri  net  models  that  use  only  one  kind  of 
token,  however,  an  MPN  model  utilizes  four  different  color-coded  token  types  for  activity  circles 
that  denote  various  activity  states  - ready,  active,  done,  and  “blocked”  (i.e.,  required  inputs  or 
resources  are  not  available  for  activity  execution).  The  software  monitors  and  records  the  various 
activity  states  during  process  simulation  so  that  such  things  as  resource  utilization  patterns,  con- 
flicts, and  process  bottlenecks  can  be  identified  and  analyzed. 

GAGE  simulations  can  be  used  as  an  aid  to  systematically  transform  an  “as-is”  model  into 
a “to-be”  improved  process  model  by  analyzing  and  comparing  the  effects  of  specific  changes  in 
the  baseline  model.  This  is  partially  supported  by  a “what-if  ’ analysis  capability  that  allows  users 
to  define  and  run  simulations  of  various  process  scenarios  in  order  to  examine  the  effects  of  poten- 
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tial  improvement  options.  Simulation  output  data  is  stored  and  can  be  viewed  using  CACE’s  lim- 
ited battery  of  simulation-based  analyses,  including  timelines  and  histograms  for  activities  and 
resources,  event  histograms,  and  aggregate  cycle/  throughput  time.  Cost  analysis  is  not  yet  part  of 
the  current  CAGE  release,  although  cost  rates  could  be  included  behind  the  scenes  via  use  of 
script  commands  or  user-defined  variables. 

5.2  DFM  Representations  and  PRP  Models  (PAR  2) 

Design-for-manufacturing  research  has  produced  some  very  good  models  that  guide  cost/ 
quality  decisions  about  product  attributes  as  they  affect  a stand-alone  activity  in  the  product  life 
cycle  (e.g.,  assembly,  injection  molding,  stamping,  etc.)  [Duffey  90,  Dastidar  91].  However,  these 
models  generally  neglect  interdependencies  between  activities  and  organizational  constraints.  To 
address  this,  Duffey  and  Dixon  examined  PRP  representation  in  a DFM  context  [Duffey  93]. 
Their  two-stage  model  (PAR  2),  implemented  as  a proof-of-concept  computer  tool,  addressed  pre- 
liminary design  (prior  to  detailed  design)  for  mechanical  assemblies.  In  the  first  stage,  two  rela- 
tional matrices  are  defined  which  i)  link  a feature-based  product  representation  to  a set  of  pre-pro- 
duction activity  classes,  and  ii)  instantiate  activities  by  linking  each  selected  activity  class  to  an 
available  resource.  In  the  second  stage,  an  activity  network  is  created  from  these  data,  and  a simu- 
lation is  run  to  obtain  an  aggregate  cash  flow  of  preproduction  costs  for  the  given  design  configu- 
ration. To  provide  data  for  the  proof-of-concept  implementation,  field  interviews  and  product/ac- 
tivity/resource documentation  were  collected  from  several  manufacturers. 

Creation  of  a product-activity  matrix  is  aided  by  common  subsets  of  activity  classes  and 
their  procedural  relationships  identified  in  the  field  research.  These  activity  templates  can  define 
graph  segments  which  are  then  connected  into  the  aggregate  activity  network.  In  general,  such  ac- 
tivity templates  are  more  standardized  for  process  realization  activities  than  for  product  realiza- 
tion activities.  For  example,  the  realization  of  progressive  die  tooling  has  a fairly  routine  ordering 
of  activities  (strip  layout,  selection  of  standard  die  components,  layout  for  die  assembly,  etc.)  that 
varies  very  little  from  one  component  to  another  (though  the  work  time  required  for  an  activity 
such  as  strip  layout  is  highly  dependent  on  part  complexity,  and  may  vary  considerably).  A tem- 
plate for  proof-of-concept  design,  however,  may  vary  tremendously  depending  on  company  prac- 
tice, functional  requirements,  technology  and  materials,  designer  experience,  and  many  other  fac- 
tors. 

Figure  1 1 shows  a representation  of  the  proof-of-concept  “template”  from  one  company 
with  two  iteration  loops  constructed  during  interviews  with  design  engineers.  The  inner  loop  {mi- 
nor-proof-change)  typically  occurs  when  minor  dimensional  changes  are  proposed  after  engineer- 
ing analysis  of  test  results  for  a proof-of-concept  model.  In  this  case,  a detail  drawing  must  be  re- 
vised, tolerances  again  reviewed  by  manufacturing,  and  the  other  activities  inside  the  loop  are  “re- 
peated,” although  often  requiring  considerably  less  time  than  the  first  iteration.  The  outer  loop 
{major-proof -change)  represents  redesign  efforts  required  after  a review  of  the  proof-of-concept 
model  by  upper  management,  including  marketing,  production,  finance,  and  other  non-engineering 
evaluations.  Typically  the  decision  to  redesign  for  this  outer  loop  requires  considerably  more  effort 
for  each  activity  in  the  loop  (i.e.,  a new  form  or  functional  concept  may  be  required,  or  new  layout 
of  the  subassembly  with  respect  to  other  subassemblies). 
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Figure  1 1 : Activity  template  for  proof-of-concept  design 

Figure  1 1 also  shows  an  additional  template  for  strip  layout  and  progressive  die  tooling  for 
a stamped  part.  When  product  redesign  is  required,  concurrent  process  activities  such  as  tooling 
may  also  need  to  be  “iterated”  to  some  greater  or  lesser  degree.  In  some  cases,  rework  for  tooling 
may  be  relatively  insignificant.  For  example,  minor  dimensional  changes  to  injection  molds  are  of- 
ten anticipated,  and  can  be  performed  with  minor  remachining  and  welding  operations.  For  more 
significant  changes  of  part  form,  however,  entire  tool  sets  may  have  to  be  scrapped  and  the  process 
begun  again.  Much  of  the  risk  evaluation  for  concurrent  product  and  process  design  involves  as- 
sessment of  possible  redesign  activity,  and  the  resulting  additional  cost  and  time  for  tooling  re- 
work. For  relatively  “stable”  designs  with  low-cost  toohng,  concurrence  makes  sense;  for  “unsta- 
ble” designs  and  high-cost  tooling,  hnear  sequencing  of  product  design  and  processing  activities 
may  actually  yield  a shorter  probable  time-to-market.  By  allowing  a design  group  to  explore  alter- 
nate “overlapping”  of  templates,  and  assign  time  and  branching  probabilities  based  on  the  best 
available  estimates,  this  model  explicitly  embodies  some  of  these  decision-making  trade-offs. 

In  this  model,  the  time  and  cost  implications  of  possible  design  “iteration”  and  changes  in 
activity  concurrency  can  be  examined  by  varying  the  model  parameters.  For  example,  die  design 
and  fabrication  for  a stamped  component  can  “overlap”  testing  for  a production  prototype  of  its 
parent  subassembly  (with  increased  cost  implications  if  downstream  problems  occur),  or  these  ac- 
tivities can  be  assigned  sequentially.  Because  of  the  explicit  relational  model  for  design  problem 
data,  aggregate  cost  and  time  information  can  be  broken  down  in  many  useful  ways:  by  product 
attribute  (for  value  engineering),  by  activity  class  (activity-based  costing  and  overhead  assign- 
ment), by  resource  (departmental  usage  and  allocation,  scheduling),  and  by  particular  cost  category 
(labor,  non-recurring,  overhead,  strategic  capital  investment,  etc.).  One  interest  is  how  this  type  of 
model  might  potentially  integrate  feature-based  CAD  representations  with  activity-based  cost  ac- 
counting methods. 
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5.3  Proposed  Extensions  to  IDEF-based  Models 

Most  recently,  in  part  due  to  increased  interest  in  process  modeling  and  in  response  to  some 
recognized  limitations  of  the  standard  IDEF  techniques,  additional  IDEF-based  representation 
schemes  such  as  IDEF3  [IICE  92],  IDEF4,  IDEF5,  and  IDEF6  have  been  introduced  as  extensions 
to  the  original  standard  IDEFO  and  IDEF IX  methodologies. 

IDEF3,  intended  as  a complementary  addition  to  the  standard  IDEFO  and  IDEF  IX  meth- 
odologies, is  primarily  a technique  for  capturing  descriptions  of  the  sequences  of  activities  within 
processes,  and  as  such  has  potential  relevance  for  PRP  modeling  efforts.  The  method  involves  the 
capture  of  information  and  assessments  about  the  objects  that  participate  in  a process,  as  well  as 
the  temporal  precedence  and  causality  relationships  between  the  activities  and  events.  As  such, 
IDEF3  adds  a missing  dimension  to  the  combined  IDEFO  and  IDEFl  representations.  However, 
IDEF3  employs  yet  another  representation  medium  of  its  own  in  the  form  of  a graphical  language 
that  is  different  from  those  used  in  the  other  IDEF  types.  The  primary  graphical  entities  of  this  lan- 
guage are  UOB  (Unit  of  Behavior)  boxes,  constraint  links,  junction  boxes,  and  referents.  In  an 
IDEF3  process  flow  diagram,  UOB  boxes,  representing  process  activities,  actions,  or  operations, 
are  connected  by  various  types  of  constraint  links,  represented  by  arrows.  Solid  arrows  denote  pre- 
cedence relationships  between  activities,  while  dashed  arrows  depict  user-defined  relations,  and 
double-headed  arrows  track  the  flow  of  objects.  Junction  boxes  depict  the  logical  structure  of  a pro- 
cess, including  the  branching  or  convergence  of  process  flows,  and  whether  parallel  branches  are 
synchronous  or  asynchronous.  Referents  can  be  included  to  assign  additional  constraints  to  junc- 
tions for  purposes  of  defining  conditions  or  decision  logic  for  branching  or  iteration.  In  addition  to 
the  process  flow  diagram,  the  IDEF3  representation  can  be  viewed  from  an  object-oriented  per- 
spective by  means  of  Object  State  Transition  Network  (OSTN)  diagrams.  These  views  cut  across 
the  process  flow  network  representation  and  enable  descriptions  of  the  objects  that  participate  in 
or  are  used  or  produced  by  activities,  tracking  their  evolution  through  a number  of  process  states. 
These  OSTN  diagrams  are  presented  in  yet  another  graphical  notation,  although  the  methodology 
provides  a cross-referencing  between  the  two  IDEF3  representations. 

5.4  Process  Modeling  within  STEP 

There  have  been  some  limited  process  modeling  efforts  by  STEP  (STandard  for  the  Ex- 
change of  Product  model  data)  developers.  EXPRESS  and  its  graphical  notation,  EXPRESS-G,  is 
an  on-going  language  development  effort  within  the  STEP  community  for  data  specification.  EX- 
PRESS was  developed  primarily  as  an  object-oriented  information  modeling,  not  a process  mod- 
eling language.  However,  there  have  been  some  efforts  to  extend  EXPRESS  for  process  modeling, 
though  with  a focus  on  physical  manufacturing  processes  [Lapointe  93].  Felser  and  Mueller  [Felser 
94]  have  proposed  an  extension  named  EXPRESS-P  which  uses  concepts  from  the  formal  lan- 
guage SDL  (Specification  and  Description  language)  employed  for  telecommunications  systems, 
and  they  have  described  an  example  application  for  injection  molding.  There  is  evidently  consid- 
erable effort  by  industry  representatives  in  the  STEP  community  to  include  some  sort  of  EX- 
PRESS-based  process  specification  language  in  EXPRESS  version  2.  However,  “enterprise  level” 
process  modeling  has  been  only  very  tentatively  discussed  at  recent  EXPRESS  User’s  Group  meet- 
ings. There  evidently  may  be  some  relevant  work  within  the  German  national  standardization  body 
DIN  (Deutsche  Industrie  Norm)  for  enterprise  process  modeling,  but  only  a few  preliminary  work- 
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ing  documents  in  the  original  language  have  been  produced  [Mueller  94].  For  related  efforts  by 
NIST  researchers,  see  referenced  work  by  Algeo,  Ray,  and  Wilson  ([Algeo  94]  (a  survey  of  lan- 
guage efforts  for  physical  manufacturing  processes)  [Ray  92,  Ray  92a]  [Wilson  91]. 

5.5  Workflow  Modeling  in  Product  Data  Management  (PDM)  Software 

There  has  also  been  work  to  integrate  PRP  modeling  concepts  with  CAD  data  by  commer- 
cial developers  of  Product  Data  Management  (PDM)  software.  Puttre  [Puttre  94]  describes  the  in- 
troduction of  “workflow  software”  by  Unigraphics,  Sherpa,  Parametrics,  and  other  companies  to 
help  track  documents  as  they  move  through  the  product  development  cycle.  Many  companies  also 
have  significant  internal  efforts  in  this  area.  For  example,  Lockheed  Missile  and  Space  Corp.  (LM- 
SC)  claims  that  their  engineering  data  management  system  for  the  Thaad  missile  program  can  now 
archive  their  product  development  process  in  considerable  detail,  including  both  review  processes 
and  efforts  of  distributed  design  teams  [Wallace  94].  However,  there  is  also  skepticism  about  the 
claims  of  vendors  for  implementing  “workflow  automation”  unless  legacy  data  systems  and  cor- 
porate cultures  are  fundamentally  changed  [Levine  94]. 

5.6  Systems  Engineering  Software  for  Product  Development  Processes 

Some  large-scale  aerospace  projects  use  one  of  several  commercial  systems  engineering 
software  packages  with  capabilities  related  to  process  modeling.  Systems  such  as  these  are  used  to 
help  create  and  track  the  flowdown  of  functional  design  requirements  into  system  components, 
task  requirements,  resources,  and  document  generation.  These  packages  have  not  yet  been  exam- 
ined by  the  authors. 

6.  Industry  PRP  Modeling  Collaborations 

In  the  course  of  this  preliminary  study,  NIST  staff  and  associated  researchers  have  partici- 
pated in  several  recent  industry  exercises  to  build  PRP  models  and  examine  existing  industry  meth- 
odologies. Some  are  discussed  below. 

6.1  Process  Modeling  for  Missile  Seeker  System 

This  case  study  was  conducted  for  several  reasons,  with  the  overall  goal  of  reducing  the 
cycle  time  to  develop  prototype  defense  systems.  It  involved  researchers  from  two  defense  indus- 
tries, several  federal  agencies  (civilian  and  military),  and  technical  consultants  (IDA,  Institute  for 
Defense  Analysis).  Process  information  was  drawn  from  current  processes  used  at  two  leading 
missile  developers.  Prior  to  development  of  the  PRP  model  a scenario  was  developed  defining  the 
initial  design  constraints  that  were  to  be  addressed  in  developing  a “brassboard”  missile  seeker  sys- 
tem. These  initial  constraints  assisted  in  limiting  the  scope  of  the  project  and  in  ensuring  conform- 
ance of  initial  starting  conditions  for  the  two  companies.  Information  used  in  the  model  was  col- 
lected (through  discussions,  presentation  materials,  project  management  PERT  charts,  organiza- 
tional descriptions,  etc.)  at  meetings  held  at  the  manufacturing  site  as  well  as  through  normal 
channels  such  as  telephone,  mail,  email,  etc.  The  industrial  representatives  also  assisted  in  defining 
how  the  PRP  models  should  be  constructed  to  best  represent  the  methods  employed  at  the  site.  The 
models  were  created  using  a tool  developed  by  Perceptronics  called  CACE/PM  (Computer-Aided 
Concurrent  Engineering/Process  Modeler).  To  exploit  certain  functionality  of  the  CACE/PM  tool. 
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information  was  sought  on  iterations,  resources  used  to  complete  activities,  and  activity  duration 
distributions.  Only  conditional  (not  probabilistic)  branching  was  specified  for  the  case  studies  in 
order  to  provide  consistent,  determinable  results  that  would  aid  in  evaluation  of  the  models.  The 
model  started  at  the  receipt  of  contract  specifications  and  finished  at  the  fabrication  of  prototype 
components  and  subsystems. 

To  compress  the  time  frame  for  the  project  it  was  decided  to  utilize  the  extensive  informa- 
tion available  from  the  companies  related  to  project  management  (e.g.,  existing  PERT  models). 
This  provided  a basis  to  develop  early  “draft”  models  that  were  used  to  enhance  data  collection 
during  the  site  visits.  During  interviews  the  draft  models  assisted  the  research  team  in  quickly  fo- 
cusing from  a high  level  view  to  the  area  of  interest  for  the  engineer  being  interviewed.  At  this 
point  the  engineer  would  redline  the  model  and  key  discussion  was  captured  in  notes  (i.e.,  organi- 
zational issues,  recommended  procedure  vs.  actual,  etc.).  To  meet  the  scoping  constraints,  the  mod- 
el was  completed  in  significantly  more  detail  in  only  two  subsystem  areas  identified  at  start  of 
project.  This  allowed  for  an  overall  high  level  model  to  be  constructed,  yet  also  achieve  the  objec- 
tive of  exploring  more  specific,  detailed  aspects  of  PRP  modeling. 

From  the  case  study,  several  issues  were  identified  that  significantly  impact  how  model  de- 
velopment proceeds.  For  example,  organizational  structure  can  have  significant  effects  on  the  de- 
velopment of  a PRP  model.  Inherent  within  well-established  organizational  structures  are  imposed 
constraints  that  can  strongly  drive  how  process  models  are  constructed.  For  organizations  that  are 
undergoing  a major  restructuring  or  re-engineering  of  the  enterprise,  the  organizational  impact  on 
model  construction  is  often  less  consequential.  With  smaller  scoped  re-engineering  efforts  this  is 
usually  not  the  case  and  models  will  tend  to  follow  guidelines  established  to  conform  to  organiza- 
tional infrastructure.  In  many  cases  this  organizational  infrastructure  is  perceived  as  providing  the 
competitive  edge  for  companies  in  responding  to  customer  requests.  Another  finding  was  that  to 
initiate  a modeling  effort  it  is  very  useful  to  start  with  existing  process  information  for  assisting  in 
model  creation.  This  can  help  “jump  start”  the  modeling  effect  yet  can  also  have  some  unanticipat- 
ed and  potentially  significant  effects.  Often  the  most  useful  documentation  are  PERT  charts  used 
for  project  management.  Although  these  materials  help  reduce  the  time  in  generating  a model  there 
is  some  concern  that  it  can  bias  a PRP  model  by  filtering  the  intended  enterprise  view  with  a project 
management  perspective.  It  is  difficult  to  surmise  the  impact  of  biasing  PRP  models  with  PM  in- 
formation. How  the  PRP  models  are  to  be  used  and  what  results  are  required  will  dictate  what  in- 
formation should  be  used  for  model  creation. 

6.2  Process  Modeling  for  Mid-sized  Scientific  Satellites 

Managers  at  the  NASA  Goddard  Space  Flight  Center  are  examining  new  process  modeling 
tools  to  help  “re-engineer”  the  mission  life  cycle  for  a new  series  of  mid-sized  scientific  satellites. 
A fairly  complex  (though  static)  model  of  the  generic  NASA  project  life-cycle  currently  exists  as 
a large  paper  diagram  which  has  the  following  top-level  phases: 

Pre-Phase  A:  Advanced  Studies 
Phase  A:  Preliminary  Analysis 
Phase  B:  Definition 
Phase  C:  Design 
Phase  D:  Development 
Phase  E:  Operations 
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NASA  managers  are  interested  in  revising  both  the  underlying  processes  and  improving  the 
tools  to  model  them  (we  have  represented  parts  of  this  process  at  NIST  using  a Petri  Net-based 
modeling  tool).  As  with  the  missile  seeker  project  described  above,  the  overriding  goal  is  to  reduce 
overall  cycle  time  for  each  satellite  mission.  Several  design  process  improvements  have  been  sug- 
gested, such  as  early  simulation  and  testing  of  power  subsystems  that  must  meet  demands  of  mul- 
tiple, independently-designed  and  built  scientific  instrument  packages.  They  also  want  to  explore 
programmatic  process  improvements,  such  as  the  complex  and  lengthy  review  process  for  pro- 
posed experiments  to  include  on  each  given  mission.  The  proposed  modeling  approach  is  based  on 
“functional  analysis”  which  is  defined  by  one  NASA  manager  as; 

A method  of  applying  a topology  to  a process  (or  series  of  processes)  in  order  to 
derive  an  understanding  of  relationships  between  elements  of  that  process;  and  fur- 
ther to  provide  a structure  which  is  used  to  allocate  those  elements  for  physical  im- 
plementation. 

This  manager  defines  three  tools  of  functional  analysis  which  will  be  necessary  for  any  ad- 
vanced modeling  tool  for  practical  use  at  NASA: 

1)  The  functional  flow  block  diagram  (FFBD):  a logical  interaction  between  func- 
tional elements. 

2)  The  requirement  allocation  sheet  (RAS):  a verbal  expansion  of  an  individual 
function,  its  associated  performance  limits  (requirements)  and  which  physical  ele- 
ment of  the  system  will  implement  it. 

3)  The  timeline  sheet  (TLS):  A pathological  “walk  through”  of  an  FFBD  to  create 
a best  guess  estimate  of  events  vs.  time. 

It  has  been  suggested  that  this  approach  to  process  modeling  may  be  best  embodied  in  sys- 
tems engineering  software  discussed  in  Section  5.6.  We  are  currently  examining  these  modeling 
paradigms,  and  their  relationship  to  other  PRP  tools  in  this  study,  in  collaboration  with  NASA  per- 
sonnel. 

6.3  Other  Industry  Process  Modeling 

Also  in  the  course  of  this  study,  several  site  visits  and  discussions  were  conducted  with  oth- 
er industries.  Engineering  managers  identified  strong  internal  needs  for  improving  and  standardiz- 
ing their  process  modeling  activities.  Documentation  on  several  current  industry  PRP  modeling 
practices  were  collected,  and  there  has  been  a strong  interest  in  future  collaboration. 

7.  Other  Applications  for  PRP  Models 

The  focus  of  this  report  has  been  on  PRP  models  as  an  aid  to  decision-making  at  the  early 
design  stage.  However,  PRP  modeling  tools  also  have  potential  for  other  applications  just  begin- 
ning to  be  addressed  in  industry  practice  or  research.  Several  (discussed  below)  include: 

• Process  archiving  after  project  completion 

• Training  and  education  applications 

• Bidding  processes 

• Real-time  process  execution 

Process  archiving.  Recently,  it  was  reported  in  the  news  media  that  much  of  the  design  pro- 
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cess  knowledge  for  the  Saturn  V program  has  been  lost  due  to  poorly  stored  documentation,  deaths 
of  key  participants,  etc.  Prototyping,  testing  and  fabrication  processes  at  the  time  did  not  use  to- 
day’s microelectronics,  and  were  in  many  ways  different  from  current  practices.  Retired  NASA  en- 
gineers speculated  that  the  Apollo  moon  launch  could  not  be  repeated  today  even  if  funding  was 
available.  New  PRP  archiving  methods  might  use  activity  networks  as  a procedural  context  for 
multi-media  such  as  video  clips  of  prototypes  and  design  review  meetings,  direct  linkage  to  FE 
analysis  results,  CAD  files,  routing  sheets,  etc.  For  example,  consider  the  value  of  an  “archived” 
process  model  which  includes  video  clips  of  prototype  failure  modes,  fabrication  processes,  and 
commentary  by  key  personnel  on  design  issues. 

Training.  Process  models  and  related  engineering  design  concepts  are  also  potentially  rel- 
evant to  training  in  a “high  performance  workplace”  [Duffey  94a].  Ideally,  an  integrated  model  of 
processes  in  an  organization  can  draw  attention  to  the  goals  and  ambitions  of  the  firm  as  a whole 
in  ways  that  may  not  be  noticeable  to  people  as  they  go  about  their  day-to-day  business.  Currently, 
“hard  copy”  process  modeling  diagrams  are  commonly  used  for  training  engineers  and  managers 
in  many  firms  (both  NASA  and  Xerox  reported  interest  in  adapting  new  PRP  modeling  methods 
for  training  new  engineers).  However,  recent  advances  in  user  interface  and  simulation  methods 
also  make  them  extremely  effective  as  training  tools  for  line  workers.  There  are  two  challenges  to 
integrating  process  modeling  tools  into  a training  environment:  1)  enable  the  “naive”  user  of  such 
models  (the  employee/student)  to  simulate  workplace  decisions  and  see  their  downstream  conse- 
quences while  keeping  the  underlying  representational  complexity  of  the  simulation  transparent. 
2)  integrate  the  process  model  in  a multimedia  context  of  video  images,  CAD  images,  etc.  For  ex- 
ample, consider  an  activity  network  that  includes  probabilistic  branching.  As  the  student  is 
“walked”  through  design  and  production  activities  with  a sequence  of  multimedia  images  and  giv- 
en different  tasks/lessons,  a random  path  generator  determines  whether  or  not  a virtual  part  the  stu- 
dent created  is  out  of  tolerance,  and  therefore  must  be  returned  to  a heat  treatment  department  for 
rework.  Using  probabilistic  branching,  each  student's  walk  through  a production  process  would  be 
unique  and  randomly  affected  by  different  common  workplace  problems.  Integration  of  process 
models  with  recent  learning  technology  ideas,  such  as  scripting  and  “drive  to  failure”  concepts  of 
pioneered  by  Roger  Schank  and  Anderson  Consulting  [Williamson  94]  might  merit  further  inves- 
tigation. 

Bidding.  One  major  initiative  to  use  process  models  for  bidding  applications  at  a large  aero- 
space manufacturer  was  reported  to  the  authors  during  preparation  of  this  report.  Also,  using  sim- 
ulation of  process  models  for  cost  and  schedule  uncertainty  is  under  investigation  for  decisions 
about  bid  pricing  and  contract  terms  in  domains  such  as  commercial  shipbuilding.  There  exists  a 
body  of  academic  research  in  this  area  [Elmaghraby  90],  but  its  extension  to  industry  practice  has 
not  been  explored.  One  related,  on-going  study  is  investigating  process  simulations  to  generate  a 
cost  probability  distribution  to  aid  bidding  decisions  for  “special”  jobs  at  a mid-sized  gear  manu- 
facturer [Duffey  94b]. 

Real-Time  Process  Execution.  Motorola  has  been  participating  in  an  ARPA-sponsored 
project  to  use  Petri  net-based  process  modeling  software  for  applications  such  as  alerting  engi- 
neers’ “beepers”  when  computer  analysis  runs  are  completed  or  prototype  testing  resources  be- 
come available. 
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8.  Other  Research  Related  to  PRP  Modeling 

Research  that  is  relevant  to  PRP  modehng  but  beyond  the  scope  of  this  report  can  be  found 
in  many  different  academic  disciplines  (e.g.,  computer  science,  mechanical  engineering,  opera- 
tions research,  management  science).  A few  studies  are  mentioned  below. 

8.1  Task  Partitioning 

There  are  several  interesting  PRP  analysis  techniques  which  might  be  integrated  in  future 
PRP  modeling  tools.  For  example,  one  task  partitioning  technique  addresses  “design  interactions,” 
a term  used  by  Whitney  to: 

express  complexity,  not  in  the  sense  that  particular  design  tasks  are  difficult  but 

rather  that  they  affect  each  other  in  circular  ways  that  are  difficult  for  designers  to 

detect  and  managers  to  control  [Whitney  90,  p.l  1]. 

Whitney  noted  that  while  design  tools  are  increasingly  available  for  component  realization 
(CAD,  FEM),  fabrication  (CNC),  and  some  system  realization  (bond  graphs,  kinematic  simula- 
tors), he  could  find  only  one  proposed  tool  for  managing  design  task  interactions.  Known  as  the 
Steward  diagram  [Steward  81],  this  simple  technique  helps  to  identify  efficient  sequencing  of  de- 
sign tasks,  and  has  been  tentatively  investigated  for  estimating  development  time  [Rogers  89,  Ep- 
pinger  90].  In  the  Steward  diagram  (also  called  a “design  structure  matrix”),  design  tasks  are  first 
assigned  as  row  and  column  labels  of  a “precedence”  matrix  in  an  arbitrary  sequence  (identical  for 
both  rows  and  columns).  Binary  elements  of  the  matrix  indicate  dependency  where  information 
from  a column  task  is  required  to  complete  a row  task.  Positive  elements  in  the  upper  right  diagonal 
of  the  matrix  indicate  coupling  between  tasks  in  the  given  sequence,  while  elements  in  the  lower 
triangle  indicate  no  coupling.  Several  methods  have  been  explored  to  reorder  (partition)  the  task 
sequence  to  minimize  coupling  and  identify  the  remaining  “blocks”  of  interdependent  tasks.  With- 
in the  remaining  blocks,  algorithms  have  also  been  devised  which  attempt  to  minimize  iteration  by 
selecting  the  best  subsequence  for  the  coupled  tasks  (termed  “tearing”  the  selected  elements  from 
the  matrix  to  initiate  iteration).  A somewhat  related  method  that  can  evaluate  task  partitions  in 
terms  of  “linkage  intensity”  was  developed  by  Yuang  and  Raz  [Yuang  1992],  and  other  research 
[Bell  92]  which  points  towards  evaluation  methods  for  process  complexity. 

Eppinger  [Eppinger  90]  has  developed  some  interesting  variations  on  the  Steward  parti- 
tioning algorithm.  By  using  numerical  elements  and  vectors  instead  of  binary  elements,  Eppinger 
explored  how  the  informational  content  of  the  matrix  could  be  enhanced  not  only  for  dependency, 
but  also  task  duration,  physical  adjacency,  and  certainty  of  information.  However,  there  remain 
some  limitations  to  the  design  structure  matrix  as  an  underlying  model  for  a management  tool. 
First,  while  experiments  have  been  conducted  using  both  management-defined  abstract  task  de- 
scriptions (“task-level”)  and  designer-defined  parameter-selection  tasks  (“parameter-level”),  there 
is  no  existing  mechanism  to  integrate  or  even  consistently  define  these  multiple  levels  of  detail. 
Second,  the  design  structure  matrix  is  only  a “static”  representation  of  tasks,  and  there  is  no  explicit 
connection  between  those  tasks  and  the  associated  product  attributes  or  resources  in  the  design  pro- 
cess. This  makes  it  difficult  to  examine  how  task  sequence  would  be  affected  by  modifications  to 
the  product  model,  or  an  alternate  allocation  of  resources.  Third,  while  schemes  to  use  the  design 
structure  matrix  to  examine  the  relative  sensitivity  of  development  time  to  task  partitioning  have 
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been  proposed,  the  actual  estimation  of  development  time,  let  alone  development  cost,  has  not  yet 
been  addressed.  Future  attempts  to  estimate  cost  and  time  from  a design  structure  matrix  may  be 
limited  by  its  ability  to  represent  and  manipulate  complex  and  often  qualitative  information  within 
its  vector  elements.  Other  interesting  research  related  to  Steward’s  task  partitioning  work  can  be 
found  in  work  by  Kusiak  [Kusiak  93]. 

8.2  Propagation  of  Design  Errors 

Clausing  states  that  the  cost  and  time  of  prototype-building  and  other  downstream  activities 
are  heavily  dependent  on  the  product  design’s  “robustness”  as  established  in  the  early  design  stage: 

In  the  best  process,  when  robustness  has  been  developed  early  concurrently  with  the 
design  of  the  product,  the  only  remaining  activity  after  the  design  has  been  complet- 
ed and  robustness  verified  is  to  concentrate  totally  upon  the  elimination  of  mistakes 
from  the  design.  There  are  literally  millions  of  design  decisions,  and  even  those  de- 
cisions where  experience  is  sufficient  will  still  have  some  mistakes,  because  even  a 
very  tiny  error  rate,  applied  to  the  huge  number  of  decisions,  will  still  result  in  hun- 
dreds of  errors.  [Clausing  90,  p.  18] 

In  general  agreement  with  Clausing,  Bailey  at  Xerox  has  suggested  a model  of  activity  in- 
terdependency in  terms  of  downstream  propagation  of  design  errors  and  their  influence  on  devel- 
opment time  [Bailey  89].  He  has  identified  three  types  of  inputs  for  a design  activity:  specifica- 
tions, technology,  and  standards.  Each  has  its  own  associated  error  type.  An  unnecessarily  precise 
weight  specification  for  a photocopier  might  result  in  an  inadequate  counter-balance  mechanism 
designed  downstream.  Designers  of  a new  paper-feeding  technology  might  neglect  to  specify  a 
feed  belt  stiffness,  resulting  in  several  prototypes  before  a required  value  was  chosen  instead  of 
being  defined  by  other  design  choices.  One  serious  type  of  standards  error  might  be  when  a metric 
screw  is  specified  but,  unknown  until  production  ramp-up,  it  is  unavailable  from  a supplier.  (Note 
that,  in  the  nomenclature  of  Eppinger’s  model,  these  are  “parameter-level”  design  activities,  but 
they  have  great  bearing  on  “task-level”  iterations  in  the  development  process.) 

Bailey’s  model  views  the  design  process  as  iteration  of  design/build/test  activities  which 
continue  until  the  product  design  “stabilizes”  enough  to  begin  production  ramp-up.  Errors  may  be 
due  to  the  input  errors  described  above  or  due  to  problems  that  occur  during  design  computations 
within  a given  iteration.  A small  simulation  to  test  his  model  requires  input  values  for  initial  design 
error  rate,  design  activity  error  rate,  test  efficiency,  and  design  complexity  (expressed  as  the  num- 
ber of  inspectable  dimensions).  The  output  is  the  expected  number  of  prototypes  prior  to  produc- 
tion ramp-up. 

8.3  Conversion  Between  Process  Representations 

Industry  demand  for  conversion  algorithms  between  different  computer-based  process  rep- 
resentations will  probably  increase  significantly  just  as  CAD  file  conversion  routines  have  become 
a persistent  (and  still  poorly  met)  demand  of  industry  users  in  the  last  fifteen  years.  Vendors  of 
IDEF-based  software  are  trying  to  provide  output  capabilities  for  both  popular  project  management 
software  and  simulation  software.  From  the  other  end,  at  least  one  well-known  simulation  software 
vendor  (CACI)  has  attempted  to  develop  routines  to  input  legacy  IDEF  models  for  its  proprietary 
activity  network  representations.  Beyond  these  vendor-specific  efforts,  only  one  conversion  re- 
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search  project  was  identified.  Elmaghraby  at  North  Carolina  State  has  an  on-going  (but  still  unpub- 
lished) project  for  conversion  of  Petri  net  models  into  a generalized  activity  network  (GAN,  see 
[Elmaghraby  77])  model  for  use  in  SLAM-based  software.  He  contends  that  Petri  net  models  are 
the  easiest  to  build  but  difficult  to  analyze,  while  the  opposite  is  true  for  SLAM-type  models,  and 
proposes  a marriage  between  the  two  representations. 

9.  Summary 

This  report  has  tried  to  present  a “bottom  up”  introduction  to  PRP  modeling  requirements 
and  practices  in  industry  which  should  drive  new  methods  and  computer  tools.  Practitioners  and 
researchers  of  PRP  models  come  from  diverse  communities  such  as  systems  engineering,  computer 
science,  mechanical  engineering,  and  management  science.  These  communities  have  very  differ- 
ent modeling  paradigms  and  the  survey  we  conducted,  though  far  from  comprehensive,  is  at  least 
representative  of  this  diversity.  Because  PRP  modeling  is  such  a new  and  burgeoning  field,  there 
is  likely  important  research  that  we  have  not  uncovered.  Also  much  of  the  “best  practice”  in  PRP 
modeling  appears  to  be  internal  to  corporate  manufacturing  and  has  not  been  disseminated.  Beyond 
U.S.  corporate  practices  and  methods,  there  are  also  likely  foreign  advances  in  PRP  modeling  that 
are  unknown  to  U.S.  practitioners  and  researchers.  We  have  also  tried  to  identify  directions  for  fu- 
ture research  in  PRP  models  in  areas  such  as  knowledge-based  process  representations,  simulation, 
and  economic  modeling. 
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